> 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).
But I used this setup even before because I like to think about "upstream" as
"more remote" than my personal fork. I like to have to explicitly call out that
I'm pulling from upstream or pushing to it.
- Ł
_______________________________________________
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/NAYOZNZVO7APEYORI2XN4VYPI64XT5FE/
Code of Conduct: http://python.org/psf/codeofconduct/
