Documenting pushdefault config option
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Documentação
- Clareza
- Razoavelmente clara
- Status de atividade
- Estagnada
- Stack de tecnologia
- git
- Domínio
- documentation
Direção de pesquisa
Revise as seções submitting e pushing changes vinculadas no devguide, juntamente com o exemplo de pushdefault em .git/config. Compare os três workflows documentados e determine qual método o guia deve recomendar; depois, atualize a documentação relevante para deixar clara essa escolha e sua configuração.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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?
- Linguagem predominante
- Python
- Estrelas
- 2.1k
- Forks
- 1k
- Merge médio
- 2d 12h
- PRs com merge (30d)
- 12
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de python/devguide
-
type-feature
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
-
type-feature
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
-
topic-building python type-feature
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
-
needs: decision topic-test type-bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
topic-dev process type-feature
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
Todas as issues de python/devguide
Issues semelhantes
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 90/100
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 86/100
zostera/django-bootstrap4#894 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
use-agent-os/agent-os#3276 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
zephyrproject-rtos/zephyr#119726 ·
-
area/auth bug comp/agent P3 platform/discord type/security
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
NousResearch/hermes-agent#117848 ·