Christian Couder <christian.couder@xxxxxxxxx> 于2021年3月25日周四 下午3:54写道： > > 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. > ------ Maybe I don't have enough right to speak on this issue, but I always think that the empty line is intentional by the designer, especially when I test it.
