[Python-Dev] Long term development external named branches and periodic merges from python

Nick Coghlan ncoghlan at gmail.com
Mon Nov 28 06:06:56 CET 2011

On Mon, Nov 28, 2011 at 2:21 PM, Jesus Cea <jcea at jcea.es> wrote:
> Since "create patch" (in the tracker) doesn't compare against the tip
> of mainline (at least not in a trivial way), I guess it is comparing
> against the BASE of the branch. That is ok... as far as I don't merge
> changes from mainline to the branch. If so, when diffing the branch
> tip from the branch base it will show all changes in the branch, both
> my code and the code imported via merges.
> So, in this context, if the tracker "create patch" diff from BASE, it
> is not "safe" to merge changes from mainline to the branch, because if
> so "create patch" would include code not related to my work.

No, "Create Patch" is smarter than that. What it does (or tries to do)
is walk back through your branch history, trying to find the last
point where you merged in a changeset that it recognises as coming
from the main CPython repo. It then uses that revision of the CPython
repo as the basis for the diff.

So if you're just working on a feature branch, periodically pulling
from hg.python.org/cpython and merging from default, then it should
all work fine.

Branches-of-branches (i.e. where you've merged from CPython via
another named branch in your local repo) seems to confuse it though -
I plan to change my workflow for those cases to merge each branch from
the same version of default before merging from the other branch.

> Anybody knows the mercurial command used to implement "create patch"?.

It's not a single command - it's a short script MvL wrote that uses
the Mercurial API to traverse the branch history and find an
appropriate revision to diff against.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list