[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...
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list