From: Jonathan Nieder <jrnieder@gmail.com>
Date: Tue, 22 Jan 2013 10:12:08 GMT
Subject: Re: [PATCH v2 01/10] sequencer.c: remove broken support for rfc2822 continuation in footer
Message-ID: <20130122101208.GC8908@elie.Belkin>
In-Reply-To: <CA+sFfMfERgGbf58LjOfAhhO_-YLu+yo+L-vYMuAuOUaP90yvgA@mail.gmail.com>

Brandon Casey wrote:
> On Mon, Jan 21, 2013 at 11:54 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>>> -             if ((buf[k] == ' ' || buf[k] == '\t') && !first)
>>> -                     continue;
>>
>> This is always the first line examined, so this "continue" never
>> triggers.
>
> This is just totally broken and always has been.  The index variable
> should be 'i' not 'k'.

Yes, now I see.

This test trips when the *next* line starts with ' ' or '\t'.

	commit, cherry-pick -s: remove broken support for multiline rfc2822 fields

	Starting with c1e01b0c (commit: More generous accepting of RFC-2822
	footer lines, 2009-10-28), "git commit -s" carefully parses the last
	paragraph of each commit message to check if it consists only of
	RFC2822-style headers, in which case the signoff will be added as a
	new line in the same list:

		Reported-by: Reporter <reporter@example.com>
		Signed-off-by: Author <author@example.com>
		Acked-by: Lieutenant <lt@example.com>

	It even included support for accepting indented continuation lines for
	multiline fields.  Unfortunately the multiline field support is broken
	because it checks whether buf[k] (the first character of the *next*
	line) instead of buf[i] is a whitespace character.  So for example, it
	confuses the following for a well-formed RFC2822 footer:

		Reported-by: Reporter <reporter@example.com>
		LINE NOISE
		 continuation
		 continuation

	A typical well-formed footer with multiline fields is not accepted:

		Reported-by: Re Porter
		 <reporter@example.com>
		Signed-off-by: Author <author@example.com>

	That this has remained broken for so long is a good sign that nobody
	actually needed continuation lines.  Rip out the broken continuation
	support.