Re: [RFC 2/3] am: semi working --cover-at-tip

From: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.de>
Date: Nov 16, 2017, 16:21 UTC
Message-ID: <4bbaaf33-3796-4aa2-6434-ab79182274f5@suse.de>
In-Reply-To: <325a3a6f-9916-29cb-48c0-69aa59e5913d@suse.de>

Le 14/11/2017 à 10:17, Nicolas Morey-Chaisemartin a écrit :

Show 14 quoted lines

>
> Le 14/11/2017 à 07:00, Junio C Hamano a écrit :
>> Nicolas Morey-Chaisemartin <NMoreyChaisemartin@suse.de> 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