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

>> > 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.
> ------