[PATCH v4 00/11] doc: interpret-trailers: explain key format

[kristofferhaugsbakk@fastmail.com]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

Topic name (applied): kh/doc-trailers

Topic summary: Explain the format of trailer keys (alphanum and
hyphens). This is important to keep in mind so that metadata is not
lost to simple syntax errors. Also replace some terms and define the
important ones upfront.

Here one change lead to another in order to make sure that everything
stayed coherent. So here’s a linear overview of the changes (as of v4):

• Patches 1–3: remove RFC 822 mentions, “metadata” term
• Patch 4: This command is not just for commit messages
• Patches 5–7: Explain the format in the simplest case, explain
  the “key” format, and add a new example
• Patch 8: join some existing paragraphs that are about the same theme
  since that makes the text flow better
• Patch 9: Also use the “trailer block” term introduced to the doc in
  patch 5 later in the doc
• Patch 10: Rewrite new-trailer paragraphs (relates to patch 8)
• Patch 11: document line comment behavior

Thanks to everyone who has been reviewing these so far. I understand that
these eleven changes are very incremental and piecemeal (see “very
cross-referenced commit messages”). And the commit messages can be quite
long, just to explain (again) very small changes. See for example patch
“replace “lines” with “metadata”” in this version, where I explain why to
write “trailer metadata” instead of “trailers metadata”. But right now I
feel like prose sometimes needs all this ceremony. With code you get
restraints like coding style, then you have all the years of looser rules
about when to use certain data structures, when to make helper methods,
etc. But with prose it seems that you bring much more of your individuality
to it. That means more choices, and many of them are not obvious to the
reader of the document, which means that you need to explain it in the
commit message. Then you also have to consider the writing history of the
document, and this one is twelve years old at this point; see the history
review in commit message “join new-trailers again”, after the thematic
break (***).

§ Changes in v4

See the patch Notes for details. Some minor things might not be mentioned
here. But they are all mentioned on the patch Notes.

Patch “add key format example”: fix doubled “to”.

Patch “commit to “trailer block” term”: simplify “blank line” mention a
little bit. But I might need some feedback from Junio on whether I
interpreted his comment correctly. There are detailed notes on the patch.

Also follow up on other copy editing feedback from Junio.[1] Note the
things that I didn’t follow up on because I disagreed or didn’t understand.

Patch “rewrite new-trailers paragraphs”: copy editing feedback from Junio.

Patch “replace “lines” with “metadata””: use “trailer metadata”. Suggested
by Matt Hunter. It reads better.

Patch “document comment line treatment”: rewrite motivation for documenting
how comment lines are treated.

🔗 1: https://lore.kernel.org/git/729baf6b-53ea-4e8d-95ab-5935667e66c2@app.fastmail.com/

§ Apologies for very cross-referenced commit messages

(see v3)

§ Cc

(see v2)

https://lore.kernel.org/git/V2_CV_doc_int-tr_key_format.613@msgid.xyz/

§ In-reply-to: v1

The recommendation to reply to the first version/cover letter is from topic
ps/doc-recommend-b4, which is in `next` right now.

§ Link to v3

https://lore.kernel.org/git/V3_CV_doc_int-tr_key_format.8a3@msgid.xyz/

[01/11] doc: interpret-trailers: stop fixating on RFC 822
[02/11] doc: interpret-trailers: replace “lines” with “metadata”
[03/11] doc: interpret-trailers: use “metadata” in Name as well
[04/11] doc: interpret-trailers: not just for commit messages
[05/11] doc: interpret-trailers: explain the format after the intro
[06/11] doc: interpret-trailers: explain key format
[07/11] doc: interpret-trailers: add key format example
[08/11] doc: interpret-trailers: join new-trailers again
[09/11] doc: interpret-trailers: commit to “trailer block” term
[10/11] doc: interpret-trailers: rewrite new-trailers paragraphs
[11/11] doc: interpret-trailers: document comment line treatment

 Documentation/git-interpret-trailers.adoc | 88 ++++++++++++++++-------
 1 file changed, 64 insertions(+), 24 deletions(-)

Interdiff against v3:
diff --git a/Documentation/git-interpret-trailers.adoc b/Documentation/git-interpret-trailers.adoc
index d5e856f5d68..b4988d39eab 100644
--- a/Documentation/git-interpret-trailers.adoc
+++ b/Documentation/git-interpret-trailers.adoc
@@ -14,7 +14,7 @@ git interpret-trailers [--in-place] [--trim-empty]
 
 DESCRIPTION
 -----------
-Add or parse trailers metadata at the end of the otherwise
+Add or parse trailer metadata at the end of the otherwise
 free-form part of a commit message, or any other kind of text.
 
 A _trailer_ in its simplest form is a key-value pair with a colon as a
@@ -66,14 +66,14 @@ Also by default, this new trailer will only be added
 if the last trailer is different to it.
 A trailer block will be created with only that trailer if a trailer
 block does not already exist. Recall that a trailer block needs to be
-preceded by a blank line, so a blank line (specifically an empty line)
-will be inserted before the new trailer block in that case.
+preceded by a blank line, so a blank line will be inserted before the
+new trailer block in that case.
 
-More concretely, this is how the new trailer is added: a `<key>=<value>`
-or `<key>:<value>` argument given using `--trailer` will be appended
-after the existing trailers. The _<key>_ and _<value>_ parts will be
-trimmed to remove starting and trailing whitespace, and the resulting
-trimmed _<key>_ and _<value>_ will appear in the output like this:
+This is how the new trailer is added: a `<key>=<value>` or
+`<key>:<value>` argument given using `--trailer` will be appended after
+the existing trailers. The _<key>_ and _<value>_ parts will be trimmed
+to remove starting and trailing whitespace, and the resulting trimmed
+_<key>_ and _<value>_ will appear in the output like this:
 
 ------------------------------------------------
 key: value
@@ -83,14 +83,14 @@ This means that the trimmed _<key>_ and _<value>_ will be separated by
 "`:`{nbsp}" (one colon followed by one space).
 
 Existing trailers are extracted from the input by looking for the
-trailer block. Concretely, that is a group of one or more lines that (i)
+trailer block. A trailer block is 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 trailer block is by definition at the end the the message. The end
-of the message in turn is either (i) at the end of the input, or (ii)
-the last non-whitespace lines before a line that starts with `---`
-(followed by a space or the end of the line).
+The trailer block is by definition at the end of the commit message.
+The message in turn is either (i) at the end of the input, or (ii) the
+last non-whitespace lines before a line that starts with `---` (followed
+by a space or the end of the line).
 
 For convenience, a _<key-alias>_ can be configured to make using `--trailer`
 shorter to type on the command line. This can be configured using the
@@ -419,8 +419,8 @@ mv "\$1.new" "\$1"
 $ chmod +x .git/hooks/commit-msg
 ------------
 
-* Here we try to to use three different trailer keys. But it fails
-  because two of them are not recognized as trailer keys.
+* Here we try to use three different trailer keys. But it fails because
+  two of them are not recognized as trailer keys.
 +
 ----
 $ cat msg.txt
Range-diff against v3:
 1:  e5d58237bc2 !  1:  2419b1a6863 doc: interpret-trailers: stop fixating on RFC 822
    @@ Metadata
      ## Commit message ##
         doc: interpret-trailers: stop fixating on RFC 822
     
    -    This command handles the trailers metadata format. But the command
    +    This command handles the trailer metadata format. But the command
         isn’t introduced as such; it is instead introduced by stating that
         these trailer lines look similar to RFC 822 email headers.
     
 2:  5ddd39bf157 !  2:  859ab42ac41 doc: interpret-trailers: replace “lines” with “metadata”
    @@ Commit message
     
         † 1: 68e3c69e (Documentation/glossary: describe "trailer", 2024-11-17)
     
    +    Let’s not emphasize “trailer” here since we are going to define the term
    +    in the upcoming commit “explain the format after the intro”.
    +
    +    Let’s call it “trailer metadata” rather than “trailers metadata”.
    +    At first it seemed better to use the latter:
    +
    +    1. We’re introducing the jargon, and the format is often discussed as
    +       plural “trailers”, with its constituent parts being singular
    +       “trailer”
    +    2. What this replaces uses “trailer”, but it rescues the plural mood
    +       with “lines”
    +    3. This is very soon going to go into the constituent parts, including
    +       each trailer, so we’re contrasting the concept name (trailers) with
    +       its parts
    +
    +    But:
    +
    +    1. The former reads better (most important)
    +    2. “Trailer *metadata*” suggests plurality, similar to “trailer *lines*”
    +
    +    Helped-by: Matt Hunter <m@lfurio.us>
         Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
     
      ## Documentation/git-interpret-trailers.adoc ##
    @@ Documentation/git-interpret-trailers.adoc: git interpret-trailers [--in-place] [
      DESCRIPTION
      -----------
     -Add or parse _trailer_ lines at the end of the otherwise
    -+Add or parse trailers metadata at the end of the otherwise
    ++Add or parse trailer metadata at the end of the otherwise
      free-form part of a commit message. For example, in the following commit
      message
      
 3:  9f0227a1978 !  3:  ab5b4af970e doc: interpret-trailers: use “metadata” in Name as well
    @@ Metadata
      ## Commit message ##
         doc: interpret-trailers: use “metadata” in Name as well
     
    -    We now since the previous commit introduce the format as “trailers
    +    We now since the previous commit introduce the format as “trailer
         metadata”. We can replace “structured information” with “metadata”
         in the “Name” section to be consistent.
     
 4:  4cb26810d4e !  4:  b79ddf3b13e doc: interpret-trailers: not just for commit messages
    @@ Documentation/git-interpret-trailers.adoc
     @@ Documentation/git-interpret-trailers.adoc: git interpret-trailers [--in-place] [--trim-empty]
      DESCRIPTION
      -----------
    - Add or parse trailers metadata at the end of the otherwise
    + Add or parse trailer metadata at the end of the otherwise
     -free-form part of a commit message. For example, in the following commit
     -message
     +free-form part of a commit message, or any other kind of text.
 5:  196c91bebe3 !  5:  e7101eb1fcb doc: interpret-trailers: explain the format after the intro
    @@ Commit message
         well as define the most important terms.
     
         Note that we name the “blank line” rule since I want to use that term
    -    every time it comes up. It gets very mildly obfuscated if you call it a
    -    “blank line” in one place[2] and “empty (or whitespace-only) ...” in
    +    every time it comes up. It gets very mildly obfuscated if you call it
    +    a “blank line” in one place[2] and “empty (or whitespace-only) ...” in
         another one.[3]
     
         We will define the format of the *key* in the next commit.
    @@ Commit message
      ## Documentation/git-interpret-trailers.adoc ##
     @@ Documentation/git-interpret-trailers.adoc: DESCRIPTION
      -----------
    - Add or parse trailers metadata at the end of the otherwise
    + Add or parse trailer metadata at the end of the otherwise
      free-form part of a commit message, or any other kind of text.
     -For example, in the following commit message
     +
 6:  688ea55599a !  6:  557b5b5564a doc: interpret-trailers: explain key format
    @@ Commit message
         Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
     
      ## Documentation/git-interpret-trailers.adoc ##
    -@@ Documentation/git-interpret-trailers.adoc: Add or parse trailers metadata at the end of the otherwise
    +@@ Documentation/git-interpret-trailers.adoc: Add or parse trailer metadata at the end of the otherwise
      free-form part of a commit message, or any other kind of text.
      
      A _trailer_ in its simplest form is a key-value pair with a colon as a
 7:  e6eafbd641f !  7:  eee81fc99fa doc: interpret-trailers: add key format example
    @@ Documentation/git-interpret-trailers.adoc: mv "\$1.new" "\$1"
      $ chmod +x .git/hooks/commit-msg
      ------------
      
    -+* Here we try to to use three different trailer keys. But it fails
    -+  because two of them are not recognized as trailer keys.
    ++* Here we try to use three different trailer keys. But it fails because
    ++  two of them are not recognized as trailer keys.
     ++
     +----
     +$ cat msg.txt
 8:  8849ace33e6 !  8:  cd3e47459c7 doc: interpret-trailers: join new-trailers again
    @@ Metadata
      ## Commit message ##
         doc: interpret-trailers: join new-trailers again
     
    -    There are three trailers that talk about how a new trailer is added.
    +    There are three paragraphs that talk about how a new trailer is added.
         But the first one is separated from the other two by two paragraphs
         about how `key-alias` can make using `--trailer` more convenient. This
         short how-to does not follow thematically from the previous paragraph,
 9:  8323b84e134 !  9:  c50b6d25170 doc: interpret-trailers: commit to “trailer block” term
    @@ Commit message
         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.
    +    *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>
     
    @@ Documentation/git-interpret-trailers.adoc: key: value
     +By default the new trailer will appear at the end of the trailer block.
     +A trailer block will be created with only that trailer if a trailer
     +block does not already exist. Recall that a trailer block needs to be
    -+preceded by a blank line, so a blank line (specifically an empty line)
    -+will be inserted before the new trailer block in that case.
    ++preceded by a blank line, so a blank line will be inserted before the
    ++new trailer block in that case.
     +
     +Existing trailers are extracted from the input by looking for the
    -+trailer block. Concretely, that is a group of one or more lines that (i)
    ++trailer block. A trailer block is 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.
    @@ Documentation/git-interpret-trailers.adoc: key: value
     -The group must either be at the end of the input or be the last
     -non-whitespace lines before a line that starts with `---` (followed by a
     -space or the end of the line).
    -+The trailer block is by definition at the end the the message. The end
    -+of the message in turn is either (i) at the end of the input, or (ii)
    -+the last non-whitespace lines before a line that starts with `---`
    -+(followed by a space or the end of the line).
    ++The trailer block is by definition at the end of the commit message.
    ++The message in turn is either (i) at the end of the input, or (ii) the
    ++last non-whitespace lines before a line that starts with `---` (followed
    ++by a space or the end of the line).
      
      For convenience, a _<key-alias>_ can be configured to make using `--trailer`
      shorter to type on the command line. This can be configured using the
10:  c7495c3b39e ! 10:  c11a116605e doc: interpret-trailers: rewrite new-trailers paragraphs
    @@ Commit message
         1. Declare that we are about to talk about `--trailer` appending
         2. Explain the default behavior
         3. Explain how this affects the trailer block
    -    4. Then state the same thing (“More concretely”) in concrete terms with
    -       placeholders
    +    4. Then discuss what each trailer line will look like
     
         Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
     
    @@ Documentation/git-interpret-trailers.adoc: are applied to each input and the way
     -using `--trailer` will be appended after the existing trailers only if
     -the last trailer has a different (_<key>_, _<value>_) pair (or if there
     -is no existing trailer). The _<key>_ and _<value>_ parts will be trimmed
    --to remove starting and trailing whitespace, and the resulting trimmed
    --_<key>_ and _<value>_ will appear in the output like this:
     +Let's consider new trailers added with `--trailer`.
     +By default, the new trailer will appear at the end of the trailer block.
     +Also by default, this new trailer will only be added
     +if the last trailer is different to it.
     +A trailer block will be created with only that trailer if a trailer
     +block does not already exist. Recall that a trailer block needs to be
    -+preceded by a blank line, so a blank line (specifically an empty line)
    -+will be inserted before the new trailer block in that case.
    ++preceded by a blank line, so a blank line will be inserted before the
    ++new trailer block in that case.
     +
    -+More concretely, this is how the new trailer is added: a `<key>=<value>`
    -+or `<key>:<value>` argument given using `--trailer` will be appended
    -+after the existing trailers. The _<key>_ and _<value>_ parts will be
    -+trimmed to remove starting and trailing whitespace, and the resulting
    -+trimmed _<key>_ and _<value>_ will appear in the output like this:
    ++This is how the new trailer is added: a `<key>=<value>` or
    ++`<key>:<value>` argument given using `--trailer` will be appended after
    ++the existing trailers. The _<key>_ and _<value>_ parts will be trimmed
    + to remove starting and trailing whitespace, and the resulting trimmed
    + _<key>_ and _<value>_ will appear in the output like this:
      
    - ------------------------------------------------
    - key: value
     @@ Documentation/git-interpret-trailers.adoc: key: value
      This means that the trimmed _<key>_ and _<value>_ will be separated by
      "`:`{nbsp}" (one colon followed by one space).
    @@ Documentation/git-interpret-trailers.adoc: key: value
     -By default the new trailer will appear at the end of the trailer block.
     -A trailer block will be created with only that trailer if a trailer
     -block does not already exist. Recall that a trailer block needs to be
    --preceded by a blank line, so a blank line (specifically an empty line)
    --will be inserted before the new trailer block in that case.
    +-preceded by a blank line, so a blank line will be inserted before the
    +-new trailer block in that case.
     -
      Existing trailers are extracted from the input by looking for the
    - trailer block. Concretely, that is a group of one or more lines that (i)
    + trailer block. A trailer block is a group of one or more lines that (i)
      is all trailers, or (ii) contains at least one Git-generated or
11:  fc38e8660f0 ! 11:  7d20cb7528f doc: interpret-trailers: document comment line treatment
    @@ Commit message
     
         Comment lines have always been ignored but this is not documented.
     
    -    This is mostly for completeness since this is unlikely to catch anyone
    -    by surprise. But we really ought to be reasonably complete here since
    -    it’s the only documentation page that documents trailers.
    +    The primary motivation here is to reasonably complete in the
    +    documentation of how trailers are parsed; this is after all the only
    +    documentation page that documents this format. However, and going beyond
    +    that point, we could imagine that someone would want to use this format
    +    outside a commit (or tag) message context, like say in Git notes.
    +
    +    On the other hand, it seems far-fetched that someone would be caught
    +    off guard by this considering that comment characters/strings are not
    +    likely to be alphanumeric,[1] which would mean that these comment lines
    +    would be treated as non-trailer lines if they were *not* detected and
    +    removed as comment lines.
    +
    +    † 1: A notable exception is that Jujutsu VCS uses `JJ:` as
    +         the comment string
     
         Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
     

base-commit: 5361983c075154725be47b65cca9a2421789e410
-- 
2.54.0.22.g9e26862b904