[Python-Dev] Re: On the migration from master to main
On Tue, 23 Mar 2021 at 21:39, Python Steering Council wrote: > > This isn’t happening because GitHub/Microsoft made a political decision. It’s > happening because it is incredibly easy to make this move, many projects have > already done this, and it reflects badly on any project not making this > change. "We do this not because it's right, but because it's easy." Great to see Python adopting the motto of our new century. Martin ___ 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/DDYQXHYATCMPD3W2OHETZLTVN5DJ4VIO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
On Tue, 4 May 2021, 10:50 am Łukasz Langa, wrote: > > On 4 May 2021, at 02:04, Łukasz Langa 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/
[Python-Dev] Re: On the migration from master to main
On 5/3/2021 9:27 PM, Terry Reedy wrote:
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?
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-branch
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.
It does.
--
Terry Jan Reedy
___
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/HTIREIDBUIFYP5YDMARDBGTBL3MSMYEA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
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-branch
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
___
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/CWXHEKLX3ZDJFOPA3ALQRPJ3DN7NM6A6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
> On 4 May 2021, at 02:04, Łukasz Langa 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/
[Python-Dev] Re: On the migration from master to main
On May 3, 2021, at 19:45, Tim Peters 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)
> upstreamhttps://github.com/python/cpython (fetch)
> upstreamhttps://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
n...@python.org -- []
___
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/OARMR5AKNYY5EWVFDKO7DUPJOHWXFHJD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
> On 4 May 2021, at 01:45, Tim Peters wrote: > > Right? Wrong? Do we need some mix of both? Something else? 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. Cheers, Łukasz ___ 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/HRLKK4QXASEAVJPPUPJMI53CJRCWIHPV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
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)
upstreamhttps://github.com/python/cpython (fetch)
upstreamhttps://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 ;-)
___
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/X3V42DYOHFLGAUPODFLXMYZWDE3VY47W/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
> f I have branch fix_something that is branched off master from a while ago, do I need to do anything to it? In general no, branches are basically a file that points to a given commit so even if they branched from master the actual commit sha is what matters. The only case if you have a branch that is tracking master as a remote, in which case you need to do those steps for said branch. But this is quite uncommon. > 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? You should be able to do that without any problem that I can foresee once you rename it in your local fork. > 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" ;-) Exactly, that's the way I reason about this as well Pablo On Fri, 26 Mar 2021 at 21:19, Paul Moore wrote: > On Fri, 26 Mar 2021 at 19:54, Mariatta 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-611263234e072dc403733b3dd46d0609cfe44b24d29f05841637b41d093adf0cR157 > > > > The details and timeline on the branch renaming can be read here: > > > > > https://mail.python.org/archives/list/python-committ...@python.org/message/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/ > > 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" ;-) > ___ > 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/EZRUP7UEBAS65QGRSTX7UF5WNGO3DXUB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/VTIWXA2KEH2WZ4MVX5OPGPJMCHCYYASK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
On Fri, 26 Mar 2021 at 19:54, Mariatta 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-611263234e072dc403733b3dd46d0609cfe44b24d29f05841637b41d093adf0cR157 > > The details and timeline on the branch renaming can be read here: > > https://mail.python.org/archives/list/python-committ...@python.org/message/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/ 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" ;-) ___ 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/EZRUP7UEBAS65QGRSTX7UF5WNGO3DXUB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
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-611263234e072dc403733b3dd46d0609cfe44b24d29f05841637b41d093adf0cR157 The details and timeline on the branch renaming can be read here: https://mail.python.org/archives/list/python-committ...@python.org/message/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/ On Fri., Mar. 26, 2021, 12:21 p.m. Skip Montanaro, wrote: > 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-master-to-main/ > > 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 > ___ > 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/ZPTBTTWIAHTMPLXEMI237LWLBDIPXZDT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/TKBEVHHYTIB3BFZIER77UNG7VDLH4AGP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
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-master-to-main/ 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 ___ 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/ZPTBTTWIAHTMPLXEMI237LWLBDIPXZDT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
On Sat, Mar 27, 2021 at 3:33 AM Baptiste Carvello wrote: > > Le 25/03/2021 à 15:59, Stefano Borini a écrit : > > On Tue, 23 Mar 2021 at 21:39, Python Steering Council > > 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. > The one thing we can agree on is that it's easier to roll over and let the change happen than to try to fight against politically-motivated changes. Politics, truth to tell, is more important than technical matters. Sometimes, it's just not worth arguing any more. ChrisA ___ 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/FZPLVZS27KXYSPHOBYQFBXZE7BW72LWQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
Le 25/03/2021 à 15:59, Stefano Borini a écrit : > On Tue, 23 Mar 2021 at 21:39, Python Steering Council > 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 ___ 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/D62N37HAFWYTXTRB5U5AQQBX3F2ODZ6C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
On Tue, 23 Mar 2021 at 21:39, Python Steering Council 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. -- Kind regards, Stefano Borini ___ 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/LNUIPXM7S5SK7VMGVHYROTLJTNIR62LM/ Code of Conduct: http://python.org/psf/codeofconduct/
