Documenting pushdefault config option
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 35/100
- Type d'issue
- Documentation
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- git
- Domaine
- documentation
Piste de recherche
Examinez les sections submitting et pushing changes du devguide accessibles via les liens, ainsi que l’exemple de pushdefault dans .git/config. Comparez les trois workflows documentés et déterminez quelle méthode le guide devrait recommander, puis mettez à jour la documentation concernée afin de clarifier ce choix et sa configuration.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
There seem to be 3 variations of the git push command:
- Use
git push origin branchnameand always specify the remote and the branch - Use
git push -u origin branchnameon the first push to setoriginas the default and then just usegit push - Set the
pushdefaulttooriginin.git/configand just usegit push
The first method is the one suggested in the devguide
(e.g. in the submitting section); the second is also documented in the pushing changes section; the third is apparently somewhat recent and not yet documented.
The pushdefault is configured by adding to .git/config:
[remote]
pushdefault = origin
Where origin refers to the user's fork of cpython. AFAICT almost all the pushes should go to origin.
Each method has pros and cons:
First method:
- pros: explicit is better than implicit
- cons: longer to type, harder to remember, could get the arg names/order wrong
Second method:
- pros: still explicit but shorter to type for the following pushes
- cons: same as above but only applies to the first push on each branch
Third method:
- pros: easier to remember, shorter to type, works like
hg push - cons: less explicit
The question is: which one should we adopt as the recommended method?
- Langage dominant
- Python
- Étoiles
- 2.1k
- Forks
- 1k
- Merge moyen
- 2 j 12 h
- PR mergées (30 j)
- 12
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de python/devguide
-
type-feature
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
type-feature
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
topic-building python type-feature
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
-
needs: decision topic-test type-bug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
topic-dev process type-feature
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
Toutes les issues de python/devguide
Issues similaires
-
Add: hunch Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
AbdelStark/awesome-typesafe#104 ·
-
enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
DiamondLightSource/dodal#2211 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
openml/openml-python#1749 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
sipyourdrink-ltd/bernstein#6191 ·