Git development
 help / color / mirror / Atom feed
From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
To: "D. Ben Knoble" <ben.knoble@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org,
	"Christian Couder" <christian.couder@gmail.com>,
	jackmanb@google.com, "Linus Arver" <linus@ucla.edu>
Subject: Re: [PATCH 2/2] doc: interpret-trailers: explain key format
Date: Tue, 31 Mar 2026 18:03:46 +0200	[thread overview]
Message-ID: <660b739f-a738-4359-92bd-cb24f5bcd624@app.fastmail.com> (raw)
In-Reply-To: <8E736B70-424E-48AC-A6D0-9A8B091D21F6@gmail.com>

On Tue, Mar 31, 2026, at 14:35, Ben Knoble wrote:
>> Le 30 mars 2026 à 18:26, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> a écrit :
>>>[snip]
>>
>> Key & value.
>>
>> Something like:
>>
>>    Just like *trailer* we emphasize these two first standalone word
>>    mentions (key and value).
>>
>> They are the only emphasized words in the diff. Although I *have* relied
>> too much on the diff context before.
>
> Perhaps “we emphasize the introduction of the terms ‘key’ and ‘value’”
> (much like a technical manual or paper may emphasize the first use of a
> new word or abbreviation, making subsequent uses link to it so readers
> can find the definition)?

I think I’ll steal that. Thanks!

> I do find it interesting that the introduction is with an example
> rather than a definition.

The example is from Linus Arver in d57fa7fc (doc: trailer: add more
examples in DESCRIPTION, 2023-06-15).[1] The version before that[2]
indirectly showed a `token: value` example (“will appear in the output
like”) after five paragraphs.

† 1: One review comment: https://lore.kernel.org/git/xmqqmt2emwlj.fsf@gitster.g/
† 2: `git show d57fa7fc73202af226b6c0^1:Documentation/git-interpret-trailers.txt`

> This suits “learning order” (concrete->abstract), but not necessarily
> “reference order” (where I just want to get to the definition). Hm.
>
> I’m not sure I have any concrete suggestions, though.

I think the only practical starting point for this format is the
simplest case first, namely:

1. One line per trailer (c.f. the value takes up multiple lines)
2. Non-empty values (see `--trim-empty`)
3. Default separator
4. No non-trailer lines
5. No configuration

Currently that starts off with two examples. But let’s try the other
way around:

***

A _trailer_ in its simplest form is a key-value pair with a colon as a
separator. The _key_ consists of ASCII alphanumeric characters and
hyphens (`-`). A _trailer block_ consists of one or more such
trailers. The trailer block needs to be preceded by a blank
line.[**1**] In other words:

    <text>

    <key>: <value>

Where <key> consists of ASCII alphanumeric characters and hyphens. For
example:

[we’re back to the original example]
------------------------------------------------
subject

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Signed-off-by: Alice <alice@example.com>
Signed-off-by: Bob <bob@example.com>
------------------------------------------------

***

Also optionally interject some words about commit messages and whatnot
(or even tag messages for that matter, now).

I was originally feeling skeptical of changing to something like
reference-first. But I like this now that I have gone through the
exercise of trying it out. So thanks for mentioning it. ;)

[**1**]: git-commit(1) stripspace behavior etc. doesn’t make this
         obvious but you can have just a blank line and then a trailer block. You
         don’t need any text before the blank line. `LF` indicates the blank
         line:

               LF
               Signed-off-by: Me

  reply	other threads:[~2026-03-31 16:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01 13:27 git-interpret-trailers and period characters in the key Brendan Jackman
2025-04-03 11:07 ` Christian Couder
2025-04-07 20:37   ` Junio C Hamano
2026-03-30 21:11 ` [PATCH 0/2] doc: interpret-trailers: explain key format kristofferhaugsbakk
2026-03-30 21:11   ` [PATCH 1/2] doc: interpret-trailers: stop fixating on RFC 822 kristofferhaugsbakk
2026-03-30 22:27     ` Junio C Hamano
2026-03-30 22:56       ` Kristoffer Haugsbakk
2026-03-30 23:24         ` Junio C Hamano
2026-03-30 21:11   ` [PATCH 2/2] doc: interpret-trailers: explain key format kristofferhaugsbakk
2026-03-30 21:55     ` Junio C Hamano
2026-03-30 22:23       ` Kristoffer Haugsbakk
2026-03-31 12:35         ` Ben Knoble
2026-03-31 16:03           ` Kristoffer Haugsbakk [this message]
2026-04-13 10:20   ` [PATCH v2 0/9] " kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 1/9] doc: interpret-trailers: stop fixating on RFC 822 kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 2/9] doc: interpret-trailers: replace “lines” with “metadata” kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 3/9] doc: interpret-trailers: use “metadata” in Name as well kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 4/9] doc: interpret-trailers: not just for commit messages kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 5/9] doc: interpret-trailers: explain the format after the intro kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 6/9] doc: interpret-trailers: explain key format kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 7/9] doc: interpret-trailers: add key format example kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 8/9] doc: interpret-trailers: commit to “trailer block” term kristofferhaugsbakk
2026-04-13 10:21     ` [PATCH v2 9/9] doc: intepret-trailers: document comment line treatment kristofferhaugsbakk
2026-04-13 13:26       ` Kristoffer Haugsbakk
2026-04-13 15:48         ` Junio C Hamano
2026-05-08 15:03           ` Kristoffer Haugsbakk
2026-05-08 15:01     ` [PATCH v2 0/9] doc: interpret-trailers: explain key format Kristoffer Haugsbakk
2026-05-11  2:41       ` Junio C Hamano
2026-05-11 19:23         ` D. Ben Knoble

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=660b739f-a738-4359-92bd-cb24f5bcd624@app.fastmail.com \
    --to=kristofferhaugsbakk@fastmail.com \
    --cc=ben.knoble@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jackmanb@google.com \
    --cc=linus@ucla.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox