Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Provide a mechanism to avoid pulling tags from upstream

Aperta
  • Qualcosa non va?
#13 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
git, python
Ambito
tooling

Direzione di ricerca

Inizia esaminando il commit 09d7ab5602404692bebcad25eea2527f0b54e7ba e la gestione attuale di projects-list per gli upstream tag. Decidi in che modo la configurazione dovrebbe distinguere i fork orientati al contributo dai fork mantenuti che hanno cambiato nome, quindi verifica che la configurazione selezionata impedisca il recupero degli upstream tag senza modificare il comportamento predefinito per i fork ordinari.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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. 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.

Lingua principale
Python
Stelle
7
Fork
5
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di jaraco/jaraco.develop

Tutte le issue di jaraco/jaraco.develop

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.