Le 14/11/2017 à 10:17, Nicolas Morey-Chaisemartin a écrit : > > Le 14/11/2017 à 07:00, Junio C Hamano a écrit : >> Nicolas Morey-Chaisemartin <[email protected]> writes: >> >> By the way, don't we want to sanity check state->last (which we >> learn by running "git mailsplit" that splits the incoming mbox into >> pieces and counts the number of messages) against state->series_len? >> Sometimes people send [PATCH 0-6/6], a 6-patch series with a cover >> letter, and then follow-up with [PATCH 7/6]. For somebody like me, >> it would be more convenient if the above code (more-or-less) ignored >> series_len and called do_apply_cover() after applying the last patch >> (which would be [PATCH 7/6]) based on what state->last says. > I thought about that. > Is there a use case for cover after the last patch works and removes the need > to touch am_next (can be done out of the loop in am_run).
Do you have an opinion on that ? It has quite a big impact on how things are done ! Single series only would mean a simple flush at the end. Multiple series makes things a whole lot complex. We do not know the series_id of the next patch until it's parsed by parse_mail. Which would mean interrupting parse_mail when detecting a new series to call parse_mail on the cover_id plus an extra detection at the end of the loop. Nicolas
