On Tue, 4 May 2021, 10:50 am Łukasz Langa, <lukasz@langa.pl> wrote:
On 4 May 2021, at 02:04, Łukasz Langa <lukasz@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.