Re: Bug in "git am" when the body starts with spaces

From: Jonathan Tan <jonathantanmy@google.com>
Date: Apr 3, 2017, 17:42 UTC
Message-ID: <f3f2b6f0-c6bb-f50a-5030-61afe941eb23@google.com>
In-Reply-To: <20170402041838.dzkmibc5lq37sm3h@sigill.intra.peff.net>

Thanks, everyone, for looking into this.

On 04/01/2017 09:18 PM, Jeff King wrote:

Show 17 quoted lines

> On Sat, Apr 01, 2017 at 12:03:44PM -0700, Linus Torvalds wrote:
>> The logic is fairly simple: if we encounter an empty line, and we have
>> pending in-body headers, we flush the pending headers, and mark us as
>> no longer in header mode.
>
> Hmm. I think this may work. At first I thought it was too strict in
> always checking inbody_header_accum.len, because we want this to kick in
> always, whether there's whitespace continuation or not. But that
> accumulator has to collect preemptively, before it knows if there's
> continuation. So it will always be non-empty if we've seen _any_ header,
> and it will remain non-empty as long as we keep parsing (because any
> time we flush, we do so in order to handle another line).
>
> IOW, I think this implements the state-machine thing I wrote in my
> earlier email, because the state "are we inside in-body header parsing"
> is always reflected by having a non-empty accumulator. It is a bit
> non-obvious though.

About obviousness, I think of a non-empty accumulator merely representing that the next line could potentially be a continuation line. And it is coincidence that this implies "are we inside in-body header parsing"; if not all in-body header lines could be "continued", there would be no such implication.

mi->inbody_header_accum.len is already used in check_inbody_header to mean "could the next line potentially be a continuation line" and to trigger a check for a negative criterion (in this case, a scissors line). I think it's fine to do the same thing, the negative criterion here being a blank line.