Merging patches

[Mauro Carvalho Chehab]

Jeremy Kerr wrote:
> Hi Martin,
> 
>> In fact, it seems that Patchwork sometimes just screws up.
>>
>> http://notmuchmail.org/pipermail/notmuch/2010/001439.html was sent
>> in direct reply to
>> http://notmuchmail.org/pipermail/notmuch/2010/001438.html, but
>> Patchwork still generated http://patchwork.madduck.net/patch/346/
>> and http://patchwork.madduck.net/patch/347/.
>>
>> Mbox with the two messages attached.
>>
>> What's wrong with that?
> 
> Nothing. Patchwork will *always* create a new patch (rather than appending to 
> an existing one) when it finds a patch in a mail.
> 
> Otherwise, the maintainer will miss patches that are hidden within other 
> patches.
> 
> From your earlier mail:
> 
>> Is it possible to merge patches instead? I don't think bundles are
>> what I want, I just want to merge two patches that do the same
>> thing, not two related patches.
> 
> I'd like to add 'relationships' between patches, but this is not a trivial 
> thing to do. A follow-up patch may be:
> 
>  * A replacement for the original patch
>  * An addition to the original patch
>  * In the same series as the original patch
>  * Completely unrelated to the original patch
> 
> So detecting this relation automatically is kinda difficult, based only on the 
> threading info.

If the follow-up patch has the in-reply-to, you can use the patch sequence number
to identify two unrelated patches on the same series (btw, it would be great to store
the patch sequence number on a series and consider it when ordering patches). Also, if
the in-reply-to were generated against a "patch 0", all the patches on the series will
refer to the same message that weren't stored. It shouldn't be hard to catch this.

For a replacement patch, you may try to use an algorithm like what -git does: get only
the diff and compare the previous and the new version. If they are very close, you may
consider the reply as a replacement.

In any case, I think that, at least, patchwork should store and display the information
that a patch has replies or that it is in reply to another patch. This makes easier for
the maintainer to not apply an older version of the patch.


-- 

Cheers,
Mauro