[Tracker-discuss] [issue415] Mercurial integration: regression in diff generation

martin at v.loewis.de martin at v.loewis.de
Sat Jan 21 14:50:35 CET 2012

> 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.

More information about the Tracker-discuss mailing list