Le 25/03/2021 à 15:59, Stefano Borini a écrit :

On Tue, 23 Mar 2021 at 21:39, Python Steering Council <steering-council@python.org> wrote:

...

This isn’t just about ‘master’ being rooted in slavery.

No it's not and I am shocked that such ignorance would exist to believe that.

It is indeed not, but the peculiar bitkeeper/git usage is. If both sides would agree on this, we could finally move on. Cheers, Baptiste

Can I distract people for a moment to ask a couple procedural questions about this change? I maintain my own fork of https://github.com/python/cpython, but don't yet see a main branch on python/cpython. - When is the new main branch supposed to appear - Once it does, what will I need to do other than to update my fork? - I have a branch in my fork (register2) which is a branch from my fork's master. Not being a Git whiz, how will I switch so my register2 branch has the new main as its upstream (I think that's the correct word)? - How long will master be around after the switch before going to that big branch in the sky? I was able to scrounge up the few commands necessary to make the change to one of my standalone projects and successfully move it from master to main. The several articles I at least peeked at all followed pretty much the same recipe as this one: https://stevenmortimer.com/5-steps-to-change-github-default-branch-from-mast... None, however, discuss how the change will affect forks. I'm a bit unclear how that part is supposed to work. I thought I might find a process PEP about this change, but saw nothing obvious in PEP 0. I'm sure this is a trivial few git commands for those more familiar with the toolchain than I am, but I see over 18k forks of the repository. I suspect a few people out of that crowd will be in the same boat as me. Thx, Skip

On Fri, 26 Mar 2021 at 19:54, Mariatta <mariatta@python.org> wrote:

The branch has not been renamed. It will be renamed after the release of beta 1.

There is a pending PR on DevGuide on how to change your existing local CPython repository to the new branch: https://github.com/python/devguide/pull/662/files#diff-611263234e072dc403733...

The details and timeline on the branch renaming can be read here:

https://mail.python.org/archives/list/python-committers@python.org/message/Q...

Thanks, that is the same set of commands I've seen in a few places. What isn't obvious to me (but may be to the people writing the documentation) is what happens to branches I have. If I have branch fix_something that is branched off master from a while ago, do I need to do anything to it? Or will I just be able to do `git merge main` once master gets renamed, and it'll just work with the name change making no difference? I suspect it *will* just work, in which case all that is needed is a brief note making that clear. But to many of us, it's not "obvious" that this is the case. Paul PS If I think hard about it, and ponder the git model of blobs and commits, etc, I can see that no commits change with the renaming, and the names "master" and "main" are just aliases for particular commits. So I think I've convinced myself that nothing else is needed. But that thought process is what I mean by "not obvious" ;-)

I'm guessing it's time to fiddle local CPython clones to account for master->main renaming now? If so, I've seen two blobs of instructions, which are very similar but not identical: Blob 1 ("origin"): """ You just need to update your local clone after the branch name changes. From the local clone of the repository on a computer, run the following commands to update the name of the default branch. $ git branch -m master main $ git fetch origin $ git branch -u origin/main main Apart from that, you should update any local script or command that uses the name "master" to use the name "main". """ Blob 2 ("upstream"): """ The CPython repository's default branch was renamed from ``master`` to ``main`` after the Python 3.10b1 release. If you had cloned the repository before this change, you can rename your local branch as follows:: git branch -m master main git fetch upstream git branch -u upstream/main main """ From my dim understanding, "upstream" makes more sense, but I don't know. On my box: """ $ git remote -v origin https://github.com/tim-one/cpython (fetch) origin https://github.com/tim-one/cpython (push) upstream https://github.com/python/cpython (fetch) upstream https://github.com/python/cpython (push) """ so sync\ing with the universally shared "upstream" just makes more sense to me. Right? Wrong? Do we need some mix of both? Something else? I'd rather get it right the first time than try to untangle a mess after the fact ;-)

On May 3, 2021, at 19:45, Tim Peters <tim.peters@gmail.com> wrote:

Blob 1 ("origin"):

""" You just need to update your local clone after the branch name changes. From the local clone of the repository on a computer, run the following commands to update the name of the default branch.

$ git branch -m master main $ git fetch origin $ git branch -u origin/main main

Apart from that, you should update any local script or command that uses the name "master" to use the name "main". """

Blob 2 ("upstream"):

""" The CPython repository's default branch was renamed from ``master`` to ``main`` after the Python 3.10b1 release. If you had cloned the repository before this change, you can rename your local branch as follows::

git branch -m master main git fetch upstream git branch -u upstream/main main """

From my dim understanding, "upstream" makes more sense, but I don't know. On my box:

""" $ git remote -v origin https://github.com/tim-one/cpython (fetch) origin https://github.com/tim-one/cpython (push) upstream https://github.com/python/cpython (fetch) upstream https://github.com/python/cpython (push) """

so sync\ing with the universally shared "upstream" just makes more sense to me.

If you are using the 'pull from "upstream", push to "origin"' naming convention that GitHub recommends, yes, Blob 2 is likely what you want to do so that "git pull" by default pulls from "upstream". If you executed Blob 1 by mistake, just doing 'git branch -u upstream/main main' should fix things up unless you have pushed commits to the master->main branch in your GitHub clome pointed to by "origin"; in that case, you may get a request to merge the two branches which you probably don't want to do. In that case, you may need to rename the branch in your origin clone (which is seldom a good idea for cpython since you aren't able to push directly to the main cpython repo) or use git log and git reset --hard to remove the offending commits, if you don't need them. If you have work-in-progress you don't want to lose, don't delete anything: it's probably easily salvageable! -- Ned Deily nad@python.org -- []

On 5/3/2021 7:45 PM, Tim Peters wrote:

I'm guessing it's time to fiddle local CPython clones to account for master->main renaming now?

If so, I've seen two blobs of instructions, which are very similar but not identical:

Blob 1 ("origin"):

""" You just need to update your local clone after the branch name changes. From the local clone of the repository on a computer, run the following commands to update the name of the default branch.

$ git branch -m master main $ git fetch origin $ git branch -u origin/main main

Apart from that, you should update any local script or command that uses the name "master" to use the name "main". """

Blob 2 ("upstream"):

""" The CPython repository's default branch was renamed from ``master`` to ``main`` after the Python 3.10b1 release. If you had cloned the repository before this change, you can rename your local branch as follows::

git branch -m master main git fetch upstream git branch -u upstream/main main """

From my dim understanding, "upstream" makes more sense, but I don't know.

For 'pull from upsteam, push to origin' workflow, https://docs.github.com/en/github/administering-a-repository/renaming-a-bran... says the 2nd, + git remote set-head origin -a + optionally, 'to remove tracking references to the old branch name' git remote prone origin When I did this, there was a '[pruned]' line for every branch ever on the fork (about 200 for me), including the bots temporary backport branches. I am now preparing a small PR and will test if creation works as usual. -- Terry Jan Reedy

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.