jaraco / jaraco/jaraco.develop
Provide a mechanism to avoid pulling tags from upstream
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 7
- Forks
- 5
- Avg merge
- 20m
- Merged PRs (30d)
- 1
Description
In 09d7ab5602404692bebcad25eea2527f0b54e7ba, I threw in a dirty hack to prevent pulling tags from upstream in the calendra project (mostly because I didn't want to figure out the git incantation). @bswck had a good suggestion to make a tag to represent this config.
## Use case
A project has forked another project into a new name but still maintains and merges changes from upstream into the fork. That's what happened with `workalendar` → [`calendra`](/jaraco/calendra). With such a fork, the maintainer likely has a different set of versions and thus probably doesn't want the upstream tags. Contrast that with a typical "fork" where the user is merely making a private clone of the repo to accommodate GitHub workflows for contributions.
## Design considerations
Presumably, there should be a simple and straightforward way to distinguish these two cases in the projects list.
One way might be to simply add a new tag "no-tags" or similar to indicate that a project should avoid pulling tags from upstream. Another might be to make that the default and require "tags" to indicate when upstream tags _should_ be pulled. Given that pulling tags is the default and probably more common scenario, it would seem preferable to have "tags" be the default.
Another way to think about it is to model the two classes of fork, a "clone" and a "fork", where the former is the typical contribution-oriented fork and the latter is the properly forked project. That would require changing the purpose of the already established "fork" tag to mean something different. One potential advantage to this approach is that it's modeling the user's intent at a higher level and may have benefits down the line for other behaviors.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing commit 09d7ab5602404692bebcad25eea2527f0b54e7ba and the current projects-list handling for upstream tags. Decide how the configuration should distinguish contribution-oriented forks from renamed maintained forks, then verify that the selected configuration prevents upstream tags from being pulled without changing the default behavior for ordinary forks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, python
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100