[Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?

Guido van Rossum guido at python.org
Sun Aug 16 16:08:03 CEST 2015


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 <larry at hastings.org> 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-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150816/33bd6bed/attachment.html>


More information about the Python-Dev mailing list