Re: Bug Report: Multi-line trailers containing empty lines break parsing

On Tue, Mar 23, 2021 at 6:39 PM Junio C Hamano [off-list ref] wrote:

Christian Couder [off-list ref] writes:

quoted

So I thought that blank lines should not appear in the trailers. And
if any appears, it means that the trailers should start after the last
blank line.

I think that is a good principle to stick to.

quoted

quoted

quoted

 - if the second "multi:" trailer did not have the funny blank line
   before "_two", the expected output would still be "multi:"
   followed by "one two three", iow, the line after the second
   "multi: one" is a total no-op?  If we added many more " \n" lines
   there, they are all absorbed and ignored?  It somehow feels wrong

That's definitely the outcome of this patch, but I agree it feels wrong.
I'm not sure that we define the behavior that strictly in
git-interpret-trailers(1), so we have some wiggle room, I guess.

Any patch to relax how blank lines and other aspects of trailers
parsing in my opinion should come with some documentation change to
explain what we now accept and what we don't accept, and also tests to
enforce that.

OK.  But do we document clearly what we accept and we don't before
any change?

Maybe it's not enough, but the doc already has the following:

------
Existing trailers are extracted from the input message by looking for
a group of one or more lines that (i) is all trailers, or (ii) contains at
least one Git-generated or user-configured trailer and consists of at
least 25% trailers.
The group must be preceded by one or more empty (or whitespace-only) lines.
The group must either be at the end of the message or be the last
non-whitespace lines before a line that starts with '---' (followed by a
space or the end of the line). Such three minus signs start the patch
part of the message. See also `--no-divider` below.

When reading trailers, there can be whitespaces after the
token, the separator and the value. There can also be whitespaces
inside the token and the value. The value may be split over multiple lines with
each subsequent line starting with whitespace, like the "folding" in RFC 822.
------