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).
I still don't believe that this is the case. Please provide some actual proof of such claims, by means of a specific repository, a specific patch created out of it, and a specific revision id of a change that should or should not have been included in the patch.
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
It seems we have to do more back and forth. If some revision of default is ancestor of B's head (by merge through A), that revision cannot possibly appear in the patch: the patch generator finds the newest revision of default that is ancestor of B. You may be misremembering: the patch *will* include changes of A that have not been merged into default. It *will not* include changes of upstream that have already been merged.
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.
Apparently, I'm incapable of describing how this patch generation works in a way that people really understand. So somebody else will have to provide the text. _______________________________________________ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
