doc: interpret-trailers: commit to “trailer block” term

We chose to introduce the term “trailer block” into the documentation a few commits ago.[1] It is used in the code though, so it is not a newly invented term. That term was useful to explain where the trailers are found (they *trail* the message). But it is also useful here, where we explain how trailers are added to existing messages, how trailer blocks are found (beyond the simple case in the introduction), and how the end of the message is found. Also note that we simplify the “blank line” point. The text says: A blank line will be added before the new trailer if there isn't one already. But this isn’t quite coherent. The previous sentence says “If there is no existing trailer”, so we are in one of these modes: 1. discussing trailer blocks in general; or 2. discussing creating a new trailer block in particular. If (1), then we shouldn’t add a blank line before the new trailer if there exists a trailer block already. And if (2), then the “if there isn’t one already” is redundant.[2] So just talking about the higher- level “trailer block” simplifies the text, since we don’t have to worry about the different contexts that *trailers* can find themselves in. † 1: in commit “explain the format after the intro” † 2: Note that non-trailer lines don’t matter here; if you have a trailer block consisting of `(cherry picked from commit <commit>)`, then you still shouldn’t insert a blank line before the new trailer since that would create a new trailer block Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Kristoffer Haugsbakk committed Jul 30, 2026 at 11:18 UTC b369d18b0881dafadaec5b564565a2d93e7ac9f5
1 file changed +14 -12
Documentation/git-interpret-trailers.adoc
+14 -12
@@ -74,19 +74,21 @@ key: value
74 This means that the trimmed _<key>_ and _<value>_ will be separated by
75 "`:`{nbsp}" (one colon followed by one space).
76
77 -By default the new trailer will appear at the end of all the existing
78 -trailers. If there is no existing trailer, the new trailer will appear
79 -at the end of the input. A blank line will be added before the new
80 -trailer if there isn't one already.
81 -
82 -Existing trailers are extracted from the input by looking for
83 -a group of one or more lines that (i) is all trailers, or (ii) contains at
84 -least one Git-generated or user-configured trailer and consists of at
77 +By default the new trailer will appear at the end of the trailer block.
78 +A trailer block will be created with only that trailer if a trailer
79 +block does not already exist. Recall that a trailer block needs to be
80 +preceded by a blank line, so a blank line will be inserted before the
81 +new trailer block in that case.
82 +
83 +Existing trailers are extracted from the input by looking for the
84 +trailer block. A trailer block is a group of one or more lines that (i)
85 +is all trailers, or (ii) contains at least one Git-generated or
86 +user-configured trailer and consists of at
87 least 25% trailers.
86 -The group must be preceded by one or more empty (or whitespace-only) lines.
87 -The group must either be at the end of the input or be the last
88 -non-whitespace lines before a line that starts with `---` (followed by a
89 -space or the end of the line).
88 +The trailer block is by definition at the end of the commit message.
89 +The message in turn is either (i) at the end of the input, or (ii) the
90 +last non-whitespace lines before a line that starts with `---` (followed
91 +by a space or the end of the line).
92
93 For convenience, a _<key-alias>_ can be configured to make using `--trailer`
94 shorter to type on the command line. This can be configured using the