Merging patches

[martin f krafft]

also sprach Mauro Carvalho Chehab <mchehab at redhat.com> [2010.02.10.2344 +1300]:
> > 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.

I don't think it's wise to rely on the series numbering in the
subject, which is simply a convention and not really a standard.

However, assuming we could identify a patch series, wouldn't it make
sense to automatically create a bundle?

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

How does Git do this?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"if ever somethin' don't feel right to you, remember what pancho said
 to the cisco kid...  `let's win, before we are dancing at the end of
 a rope, without music.'"
                                                             -- sailor
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20100211/fac70866/attachment.pgp>