Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
On Sun, Aug 16, 2015 at 7:08 AM, Guido van Rossum wrote: > (I'm only familiar with the GitHub PR flow, and I don't like its behavior, > which seems to always create an extra merge revision for what I consider as > logically a single commit.) For whatever it's worth, this is a "feature": the extra merge revision serves as a record of the fact that a PR was merged, who merged it, and what the state of the branch was before and after the merge (useful in case the PR contains multiple revisions that are all getting merged together). These are all things that git makes impossible to reconstruct after the fact otherwise, because it stores no metadata about which branch each revision started out in. But if you consistently make a merge commit every time, then 'git log --first-parent' will reliably show one entry per merged PR. -n -- Nathaniel J. Smith -- http://vorpus.org ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
On 08/16/2015 07:08 AM, Guido van Rossum wrote: I presume the issue here is that Hg is so complicated that everyone knows a different subset of the commands and semantics. I personally don't know what the commands for cherry-picking a revision would be. There are a couple. The command you'd want for this use case is probably "hg transplant", because it lets you pull revisions from a different repo. Note that "transplant" is an extension; it's distributed with Mercurial but is turned off by default. (Presumably because it's an "unloved" feature, which seems to translate roughly to "deprecated and only minimally supported".) The Mercurial team recommends "graft", and they also provide "rebase", but neither of those can pull revisions from another repo. Since all revisions committed to 3.5.0 should be merged into 3.5.1 sooner or later, personally I don't see the *need* for cherry-picking. I also don't know exactly what happens when you merge a PR using bitbucket. (I'm only familiar with the GitHub PR flow, and I don't like its behavior, which seems to always create an extra merge revision for what I consider as logically a single commit.) Bitbucket doesn't appear to create any extraneous merge revisions. Of the two PRs I've accepted, only one created a merge, and that was sensible. BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I see (in a very big bold font) is "This is Python version 3.6.0 alpha 1". What's going on here? It doesn't inspire confidence. It was displaying the readme from the default branch. We use the 3.5 branch. I just went and looked, and there's a "default branch" option for the repo on Bitbucket. I changed it from "default" to "3.5" and now it displays "This is Python version 3.5.0 release candidate 1". Hopefully that inspires more confidence! / /arry/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
On Sun, 16 Aug 2015 11:24:32 -0400, "R. David Murray" wrote: > On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings wrote: > > 3. After your push request is merged, you pull from > > bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge > > into 3.5. In this version I don't have to do a final null merge! > > > > I'd prefer 3; that's what we normally do, and that's what I was > > expecting. So far people have done 1 and 2. Thinking about this some more I realize why I was confused. My patch/pull request was something that got committed to 3.4. In that case, to follow your 3 I'd have to leave 3.4 open until you merged the pull request, and that goes against our normal workflow. Maybe my patch will be the only exception... --David ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
On 16.08.2015 16:08, Guido van Rossum wrote: > I presume the issue here is that Hg is so complicated that everyone knows a > different subset of the commands and semantics. > > I personally don't know what the commands for cherry-picking a revision > would be. > > I also don't know exactly what happens when you merge a PR using bitbucket. > (I'm only familiar with the GitHub PR flow, and I don't like its behavior, > which seems to always create an extra merge revision for what I consider as > logically a single commit.) > > BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I > see (in a very big bold font) is "This is Python version 3.6.0 alpha 1". > What's going on here? It doesn't inspire confidence. You are probably looking at the default branch within that repo fork. This is the 3.5 branch: https://bitbucket.org/larry/cpython350/branch/3.5 > On Sun, Aug 16, 2015 at 10:13 AM, Larry Hastings wrote: > >> >> >> So far I've accepted two pull requests into bitbucket.com/larry/cpython350 >> in the 3.5 branch, what will become 3.5.0rc2. As usual, it's the >> contributor's responsibility to merge forward; if their checkin goes in to >> 3.5, it's their responsibility to also merge it into the >> hg.python.org/cpython 3.5 branch (which will be 3.5.1) and default branch >> (which right now is 3.6). >> >> But... what's the plan here? I didn't outline anything specific, I just >> assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and >> merging. But of the two pull requests so far accepted, one was merged this >> way, though it cherry-picked the revision (skipping the pull request merge >> revision Bitbucket created), and one was checked in to 3.5.1 directly (no >> merging). >> >> I suppose we can do whatever we like. But it'd be helpful if we were >> consistent. I can suggest three approaches: >> >>1. After your push request is merged, you cherry-pick your revision >>from bitbucket.com/larry/cpython350 into hg.python.org/cpython and >>merge. After 3.5.0 final is released I do a big null merge from >>bitbucket.com/larry/cpython350 into hg.python.org/cpython. >>2. After your push request is merged, you manually check in a new >>equivalent revision into hg.python.org/cpython in the 3.5 branch. No >>merging necessary because from Mercurial's perspective it's unrelated to >>the revision I accepted. After 3.5.0 final is released I do a big null >>merge from bitbucket.com/larry/cpython350 into hg.python.org/cpython. >>3. After your push request is merged, you pull from >>bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge >>into 3.5. In this version I don't have to do a final null merge! >> >> I'd prefer 3; that's what we normally do, and that's what I was >> expecting. So far people have done 1 and 2. >> >> Can we pick one approach and stick with it? Pretty-please? >> >> >> */arry* >> >> ___ >> python-committers mailing list >> python-committ...@python.org >> https://mail.python.org/mailman/listinfo/python-committers >> >> > > > > > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 16 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2015-08-12: Released mxODBC 3.3.4 ... http://egenix.com/go80 2015-08-22: FrOSCon 2015 ...6 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
On 2015-08-16, at 16:08 , Guido van Rossum wrote: > I presume the issue here is that Hg is so complicated that everyone knows a > different subset of the commands and semantics. > > I personally don't know what the commands for cherry-picking a revision would > be. graft > I also don't know exactly what happens when you merge a PR using bitbucket. > (I'm only familiar with the GitHub PR flow, and I don't like its behavior, > which seems to always create an extra merge revision for what I consider as > logically a single commit.) Same thing IIRC, I don't think there's a way to "squash" a merge via the web interface in either. > BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I see > (in a very big bold font) is "This is Python version 3.6.0 alpha 1". What's > going on here? It doesn't inspire confidence. It's the rendered content of the README file at the root of the repository, same as github.___ 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/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
I presume the issue here is that Hg is so complicated that everyone knows a different subset of the commands and semantics. I personally don't know what the commands for cherry-picking a revision would be. I also don't know exactly what happens when you merge a PR using bitbucket. (I'm only familiar with the GitHub PR flow, and I don't like its behavior, which seems to always create an extra merge revision for what I consider as logically a single commit.) BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I see (in a very big bold font) is "This is Python version 3.6.0 alpha 1". What's going on here? It doesn't inspire confidence. On Sun, Aug 16, 2015 at 10:13 AM, Larry Hastings wrote: > > > So far I've accepted two pull requests into bitbucket.com/larry/cpython350 > in the 3.5 branch, what will become 3.5.0rc2. As usual, it's the > contributor's responsibility to merge forward; if their checkin goes in to > 3.5, it's their responsibility to also merge it into the > hg.python.org/cpython 3.5 branch (which will be 3.5.1) and default branch > (which right now is 3.6). > > But... what's the plan here? I didn't outline anything specific, I just > assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and > merging. But of the two pull requests so far accepted, one was merged this > way, though it cherry-picked the revision (skipping the pull request merge > revision Bitbucket created), and one was checked in to 3.5.1 directly (no > merging). > > I suppose we can do whatever we like. But it'd be helpful if we were > consistent. I can suggest three approaches: > >1. After your push request is merged, you cherry-pick your revision >from bitbucket.com/larry/cpython350 into hg.python.org/cpython and >merge. After 3.5.0 final is released I do a big null merge from >bitbucket.com/larry/cpython350 into hg.python.org/cpython. >2. After your push request is merged, you manually check in a new >equivalent revision into hg.python.org/cpython in the 3.5 branch. No >merging necessary because from Mercurial's perspective it's unrelated to >the revision I accepted. After 3.5.0 final is released I do a big null >merge from bitbucket.com/larry/cpython350 into hg.python.org/cpython. >3. After your push request is merged, you pull from >bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge >into 3.5. In this version I don't have to do a final null merge! > > I'd prefer 3; that's what we normally do, and that's what I was > expecting. So far people have done 1 and 2. > > Can we pick one approach and stick with it? Pretty-please? > > > */arry* > > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers > > -- --Guido van Rossum (python.org/~guido) ___ 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/archive%40mail-archive.com
