ZheNing Hu <adlternative@xxxxxxxxx> writes: > Christian Couder <christian.couder@xxxxxxxxx> 于2021年3月25日周四 下午3:54写道： >> >> 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. People like you, who is relatively new to the system and the list, are valuable source of information for us to learn where in the current system and documentation we have room to improve and clarify. You do have right, and we welcome your input. Care to clarify what you mean by "the empty line is intentional by the designer"? The designer of the current "trailer" intended to make the "last paragraph" (where "paragraph" is defined as a run of lines without an empty line in it, so that one or more continguous empty lines separate "paragraphs") where the trailers sit in the log message. Is that what you mean? Or something else?
