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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks, everyone, for looking into this.

On 04/01/2017 09:18 PM, Jeff King wrote:
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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]