Brandon Casey wrote:
> On Mon, Jan 21, 2013 at 11:54 PM, Jonathan Nieder <[email protected]> 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 <[email protected]>
Signed-off-by: Author <[email protected]>
Acked-by: Lieutenant <[email protected]>
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 <[email protected]>
LINE NOISE
continuation
continuation
A typical well-formed footer with multiline fields is not accepted:
Reported-by: Re Porter
<[email protected]>
Signed-off-by: Author <[email protected]>
That this has remained broken for so long is a good sign that nobody
actually needed continuation lines. Rip out the broken continuation
support.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
