Nick Coghlan <ncogh...@gmail.com> added the comment: If you get repeated application of upstream changes in generated patches, it's a sign that the patch generator is having trouble finding the right base version to compare against. Usually this happens due to daisy chaining of merges, so a CPython version gets merged, but never appears directly as an ancestor of the revision that is being merge (instead, the relevant CPython version appears only as an ancestor of the alternate branch of a merge commit).
For example, I used to have this problem all the time when I was running two feature branches in my sandbox repo, where feature B depended on feature A. If I did the merge flow of upstream changes as default->A->B then the diffs generated for the B branch were always useless (they included changes already part of upstream). After much back and forth with Martin, we figured out that this was the problem and changing my merge workflow to be default->A, default->B, and only doing A->B merges when A itself changed, would allow the automatic patch generator to do the right thing. Another way to get yourself in trouble is to merge directly from hg.python.org into a feature branch, then merge that feature branch into your default branch - again, the patch generator can't see the correct CPython revision in that case (because it is off on the feature branch, not on default). So nothing's actually changed here, but the constraints on merge practices if you want the patch generator to produce correct patches could use a solid explanation somewhere in the devguide. ---------- nosy: +ncoghlan _______________________________________________________ PSF Meta Tracker <metatrac...@psf.upfronthosting.co.za> <http://psf.upfronthosting.co.za/roundup/meta/issue415> _______________________________________________________ _______________________________________________ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
