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

Nick Coghlan ncoghlan at gmail.com
Thu Nov 24 23:45:58 CET 2011

On Fri, Nov 25, 2011 at 7:23 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Am 24.11.2011 21:55, schrieb Nick Coghlan:
>> I've never been able to get the Create Patch button to work reliably
>> with my BitBucket repo, so I still just run "hg diff -r default" locally
>> and upload the patch directly.
> Please submit a bug report to the meta tracker.

Done: http://psf.upfronthosting.co.za/roundup/meta/issue428

>> It would be nice if I could just specify both the feature branch *and*
>> the branch to diff against rather than having to work out why Roundup is
>> guessing wrong...
> Why would you not diff against the default branch?

I usually do - the only case I have at the moment where diffing
against a branch other than default sometimes make sense is the
dependency from the PEP 380 branch on the dis.get_opinfo() feature
branch (http://bugs.python.org/issue11682).

In fact, I believe that's also the case that confuses the diff generator.

My workflow in the repo is:

- update default from hg.python.org/cpython
- merge into get_opinfo branch from default
- merge into pep380 branch from the get_opinfo branch

So, after merging into the pep380 branch, "hg diff -r default" gives a
full patch from default -> pep380 (including the dis module updates),
while "hg diff -r get_opinfo" gives a patch that assumes the dis
changes have already been applied separately.

I'm now wondering if doing an explicit "hg merge default" before I do
the merges from the get_opinfo branch in my sandbox might be enough to
get the patch generator back on track...


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

More information about the Python-Dev mailing list