On Tue, Mar 23, 2021 at 6:39 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Christian Couder <christian.couder@xxxxxxxxx> writes: > > > 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. > > >> > - 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. ------
