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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4