[PATCH 0/3] Add basic support for series of patches
jk at ozlabs.org
Tue Jan 8 13:59:32 EST 2013
> * It looks like "In-Reply-To" isn't super easy as a method for
> collecting groups of patches since git send-email can run in a number
> of different modes (chained replies vs not and also the "in-reply-to"
> option). It could be used (and would be more robust than my
> heuristics), but we need to be careful to test all of the different
Yes, and I think we can handle all of these, especially as we keep the
message-id of every patch and comment; we could scan the contents of the
In-Reply-To and References header looking for linkages to patches in the
> * In practice, the heuristics that I've used seem to work really well
> to identify groups of patches. I have yet to see them fail as long as
> all of the patches are actually visible.
I was planning to use some of your logic in the patch parser too :)
>> One really helpful thing would be some contributions for testcases;
>> especially when the parser receives patches out-of-order.
> What format are you looking for for test cases? I'm happy to dig
> through email folders and find some interesting ones.
Ideally, these would be additions to the existing tests in
apps/patchwork/tests. Check out patchparser.py in particular. Of course,
this will depend on which implementation we end up using, so maybe just
collect a few examples of different threading styles for now.
More information about the Patchwork