My fork lacks a 3.7 branch - can I create it somehow?
My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch was created. I have no remotes/origin/3.7. Is there some way to create it from remotes/upstream/3.7? I asked on GitHub's help forums. The only recommendation was to to delete my fork and recreate it. That seemed kind of drastic, and I will do it if that's really the only way, but this seems like functionality Git and/or GitHub probably supports. Thx, Skip
On Tue, May 22, 2018 at 10:07 AM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch was created. I have no remotes/origin/3.7. Is there some way to create it from remotes/upstream/3.7? I asked on GitHub's help forums. The only recommendation was to to delete my fork and recreate it. That seemed kind of drastic, and I will do it if that's really the only way, but this seems like functionality Git and/or GitHub probably supports.
Create it from upstream? Yep! Try this: git checkout -b 3.7 upstream/3.7 git push -u origin 3.7 That'll probably have to chug-chug-chug to push all that content up to GitHub; AFAIK they don't have any optimization for "this commit already exists in another fork of this repository", so you'll have to upload everything as if it's completely new. But other than that, it should be quick and easy. ChrisA
On Tue, May 22, 2018 at 10:45 AM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
Create it from upstream? Yep! Try this:
git checkout -b 3.7 upstream/3.7 git push -u origin 3.7
Thanks, Chris! Didn't have to chug for too long either, just a few seconds.
S
Perfect! I'm used to doing this sort of thing with long histories that need to be synchronized, so there can be minutes of uploading. But I guess here "3.7" is very close to "master", so there's not as much to sync. Even easier! :) ChrisA
On 22.05.2018 3:07, Skip Montanaro wrote:
My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch was created. I have no remotes/origin/3.7. Is there some way to create it from remotes/upstream/3.7? I asked on GitHub's help forums. The only recommendation was to to delete my fork and recreate it. That seemed kind of drastic, and I will do it if that's really the only way, but this seems like functionality Git and/or GitHub probably supports.
Thx, You don't really need copies of official branches on your Github fork if you're not a maintainer for these branches. (You'll have to keep master though AFAIK since Git needs some branch to be marked as "default".)
It's sufficient to just have topic branches for PRs there: you take official branches from python/cpython and topic branches from your fork, do the edits and manipulations locally, then upload the changed topic branches to your fork. I found this easier than having everything in your fork 'cuz it saves you the hassle of keeping your copies up-to-date and having unexpected merge conflicts in your PRs if the copies get out of date.
Skip _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru
-- Regards, Ivan
You don't really need copies of official branches on your Github fork if you're not a maintainer for these branches.
I explicitly wanted to run with 3.7 in the run-up to release. On that branch, the built ./python reports 3.7.0b4+ at startup. Master tells me 3.8.0a0 on startup. Since my local repo is a clone of my fork, it made sense to me to have a 3.7 branch on my fork which I could switch to. Am I only nutcase who thinks that might be mildly useful? (Or that if I want to test an application across multiple versions using tox that it makes sense to have pre-release visibility of point releases.) Skip
On May 22, 2018, at 18:51, Skip Montanaro <skip.montanaro@gmail.com> wrote:
[Ivan Pozdeev]:
You don't really need copies of official branches on your Github fork if you're not a maintainer for these branches. I explicitly wanted to run with 3.7 in the run-up to release. On that branch, the built ./python reports 3.7.0b4+ at startup. Master tells me 3.8.0a0 on startup. Since my local repo is a clone of my fork, it made sense to me to have a 3.7 branch on my fork which I could switch to. Am I only nutcase who thinks that might be mildly useful? (Or that if I want to test an application across multiple versions using tox that it makes sense to have pre-release visibility of point releases.)
No, what you what you want to do makes perfect sense. It sounds like Ivan is used to projects with a somewhat different workflow than ours. We don't have "branch maintainers"; core-developers are responsible themselves for merging changes into all appropriate branches. While these days some of the backporting can be semi-automated, thanks to the backport bot, but it is still up to the core developer to decide whether a change can and should be backported, so having all active branches available in a local repo is a pretty much a necessity. As always, the Developer's Guide should be able to answer questions like this: https://devguide.python.org/devcycle/ -- Ned Deily nad@python.org -- []
On Tue, May 22, 2018 at 3:51 PM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
You don't really need copies of official branches on your Github fork if you're not a maintainer for these branches.
I explicitly wanted to run with 3.7 in the run-up to release. On that branch, the built ./python reports 3.7.0b4+ at startup. Master tells me 3.8.0a0 on startup. Since my local repo is a clone of my fork, it made sense to me to have a 3.7 branch on my fork which I could switch to. Am I only nutcase who thinks that might be mildly useful? (Or that if I want to test an application across multiple versions using tox that it makes sense to have pre-release visibility of point releases.)
To run with 3.7 you need 3.7 in your local repo, but there's no particular reason that you need to push that branch back up to your personal fork on github. It's very unlikely that anyone looking for a 3.7 branch would go to your fork and expect to find it there. As far as git is concerned, the main repo on github, your fork on github, and your local repo are 3 independent repositories, equally valid. The relationships between them are purely a matter of convention. -n -- Nathaniel J. Smith -- https://vorpus.org
[Nathaniel Smith <njs@pobox.com>]
... As far as git is concerned, the main repo on github, your fork on github, and your local repo are 3 independent repositories, equally valid. The relationships between them are purely a matter of convention.
Thanks for that! It instantly cleared up several mysteries for me. I'm just starting to learn git & github, and am starkly reminded of an old truth: there is absolutely nothing "obvious" about source-control systems, or workflows, before you already know them ;-)
On Tue, 22 May 2018 19:10:49 -0500 Tim Peters <tim.peters@gmail.com> wrote:
[Nathaniel Smith <njs@pobox.com>]
... As far as git is concerned, the main repo on github, your fork on github, and your local repo are 3 independent repositories, equally valid. The relationships between them are purely a matter of convention.
Thanks for that! It instantly cleared up several mysteries for me. I'm just starting to learn git & github, and am starkly reminded of an old truth: there is absolutely nothing "obvious" about source-control systems, or workflows, before you already know them ;-)
I think you'll find out that git can be especially non-obvious :-) Regards Antoine.
On 23 May 2018 at 09:14, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 22 May 2018 19:10:49 -0500 Tim Peters <tim.peters@gmail.com> wrote:
Thanks for that! It instantly cleared up several mysteries for me. I'm just starting to learn git & github, and am starkly reminded of an old truth: there is absolutely nothing "obvious" about source-control systems, or workflows, before you already know them ;-)
I think you'll find out that git can be especially non-obvious :-)
My understanding is that git becomes more obvious when you understand that it's not actually a source control system at all but rather a data model for text and changes. (Or something like that, I haven't reached that level of enlightenment myself yet...) Paul
On 23 May 2018 at 19:25, Paul Moore <p.f.moore@gmail.com> wrote:
On 23 May 2018 at 09:14, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 22 May 2018 19:10:49 -0500 Tim Peters <tim.peters@gmail.com> wrote:
Thanks for that! It instantly cleared up several mysteries for me. I'm just starting to learn git & github, and am starkly reminded of an old truth: there is absolutely nothing "obvious" about source-control systems, or workflows, before you already know them ;-)
I think you'll find out that git can be especially non-obvious :-)
My understanding is that git becomes more obvious when you understand that it's not actually a source control system at all but rather a data model for text and changes. (Or something like that, I haven't reached that level of enlightenment myself yet...)
For data structure wonks, http://eagain.net/articles/git-for-computer-scientists/ can be more informative than any number of git usage guides :) The mapping from command line incantations to their effect on the DAG can be a little (*cough*) obscure, but having the right mental model of what's going on at a data structure level can still help enormously. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Tim Peters writes:
there is absolutely nothing "obvious" about source-control systems, or workflows, before you already know them ;-)
Obvious, adj.: More an expletive than a true adjective, shows a state of mind in which the speaker is comfortable that a statement fits her preconceptions. Conveys little, if any, information. Syn.: intuitive, natural. -- The *New* New Devil's Dictionary
participants (10)
-
Antoine Pitrou -
Chris Angelico -
Ivan Pozdeev -
Nathaniel Smith -
Ned Deily -
Nick Coghlan -
Paul Moore -
Skip Montanaro -
Stephen J. Turnbull -
Tim Peters