Brandon Casey wrote: > On Mon, Jan 21, 2013 at 11:54 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> 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@xxxxxxxxxxx> Signed-off-by: Author <author@xxxxxxxxxxx> Acked-by: Lieutenant <lt@xxxxxxxxxxx> 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@xxxxxxxxxxx> LINE NOISE continuation continuation A typical well-formed footer with multiline fields is not accepted: Reported-by: Re Porter <reporter@xxxxxxxxxxx> Signed-off-by: Author <author@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html