Christian Couder <christian.couder@xxxxxxxxx> writes: >> > 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: OK. The next step is to find out if there is anything unclear in the description of the current behaviour in that paragraph that may have resulted in the report of the "bug" that turned out to be a non-bug. > ------ > 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. > ------ Thanks.
