On Tue, 4 May 2021, 10:50 am Łukasz Langa, <luk...@langa.pl> wrote: > > On 4 May 2021, at 02:04, Łukasz Langa <luk...@langa.pl> wrote: > > Having renamed the branch in my fork first, the exact sequence I used on > my own clone was: > > ❯ git checkout master > ❯ git branch -m master main > ❯ git fetch origin > ❯ git branch -u origin/main main > ❯ git remote set-head origin -a > ❯ git fetch upstream > ❯ git remote set-head upstream -a > ❯ git pull upstream main > > This worked, I can successfully pull from upstream's main and push to my > upstream's main. The `set-head` ones were suggested by the GitHub UI and > ended up with heads explicitly being listed in `git log` which I guess is > harmless. > > > Seeing Ned's and Mariatta's comments on the matter I guess I should > clarify that my commands above are for a *symmetrical* setup, i.e. where > I expect the default `git pull` to *pull from origin*, and the default > `git push` to *push to origin*. > > I might not be your typical user here, since I actually push to upstream > too every now and again as part of release management, in particular > pushing out signed release tags (which are full git objects with the same > metadata as commits). >
The dev guide (and Github) have long recommended this arrangement, so I believe it's those of us that define a separate "pr" remote for our fork and have "origin" referring to the main CPython repo that are the odd ones out. Cheers, Nick. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5KXVPXAJYFRJCT3RGQ4SC22NEM6IUKBE/ Code of Conduct: http://python.org/psf/codeofconduct/
