git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 17/17] Documentation: add documentation for 'git interpret-trailers'

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Jan 27, 2014, 00:52 UTC
Message-ID
<CAPig+cQgq_2h+n8OeDsrmk_NqAA4RDNzkBAtNCNjOAGMrFN4jg@mail.gmail.com>
In-Reply-To
<20140126170011.24291.26146.chriscool@tuxfamily.org>

On Sun, Jan 26, 2014 at 12:00 PM, Christian Couder <chriscool@tuxfamily.org> wrote:

Show 19 quoted lines
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
> new file mode 100644
> index 0000000..f74843e
> --- /dev/null
> +++ b/Documentation/git-interpret-trailers.txt
> @@ -0,0 +1,137 @@
> +git-interpret-trailers(1)
> +=========================
> +
> +NAME
> +----
> +git-interpret-trailers - help add stuctured information into commit messages
> +
> +SYNOPSIS
> +--------
> +[verse]
> +'git interpret-trailers' [--trim-empty] [--infile=file] [<token[=value]>...]
Would it be more consistent with existing documentation to format this as so?
  [--infile=<file>] [<token>[=<value>]]...
> +DESCRIPTION
> +-----------
> +Help add RFC 822 like headers, called 'trailers', at the end of the
s/822 like/822-like/

Was the suggestion, early in the discussion, to use "footer" rather than "trailer" dismissed?

> +otherwise free-form part of a commit message.
> +
> +Unless `--infile=file` is used, this command is a filter. It reads the
> +standard input for a commit message and apply the `token` arguments,
s/apply/applies/
Show 12 quoted lines
> +if any, to this message. The resulting message is emited on the
> +standard output.
> +
> +Some configuration variables control the way the `token` arguments are
> +applied to the message and the way any existing trailer in the message
> +is changed. They also make it possible to automatically add some
> +trailers.
> +
> +By default, a 'token=value' or 'token:value' argument will be added
> +only if no trailer with the same (token, value) pair is already in the
> +message. The 'token' and 'value' parts will be trimmed to remove
> +starting and trailing white spaces, and the resulting trimmed 'token'

Other git documentation uniformly spells it as "whitespace" rather than "white spaces".

Show 8 quoted lines
> +and 'value' will appear in the message like this:
> +
> +------------------------------------------------
> +token: value
> +------------------------------------------------
> +
> +By default, if there are already trailers with the same 'token' the
> +trailer will appear just after the last trailer with the same
It might be a bit clearer to say "the _new_ trailer will appear...".
Show 10 quoted lines
> +'token'. Otherwise it will appear at the end of the message.
> +
> +Note that 'trailers' do not follow and are not intended to follow many
> +rules that are in RFC 822. For example they do not follow the line
> +breaking rules, the encoding rules and probably many other rules.
> +
> +Trailers have become a de facto standard way to add helpful structured
> +information into commit messages. For example the well known
> +"Signed-off-by: " trailer is used by many projects like the Linux
> +kernel and Git.

This "justification" paragraph might make more sense near or at the very the top of the Description section.

> +OPTIONS
> +-------
> +--trim-empty::
> +       If the 'value' part of any trailer contains onlywhite spaces,
s/onlywhite spaces/only whitespace/
Show 25 quoted lines
> +       the whole trailer will be removed from the resulting message.
> +
> +----infile=file::
> +       Read the commit message from `file` instead of the standard
> +       input.
> +
> +CONFIGURATION VARIABLES
> +-----------------------
> +
> +trailer.<token>.key::
> +       This 'key' will be used instead of 'token' in the
> +       trailer. After some alphanumeric characters, it can contain
> +       some non alphanumeric characters like ':', '=' or '#' that will
> +       be used instead of ':' to separate the token from the value in
> +       the trailer, though the default ':' is more standard.
> +
> +trailer.<token>.where::
> +       This can be either `after`, which is the default, or
> +       `before`. If it is `before`, then a trailer with the specified
> +       token, will appear before, instead of after, other trailers
> +       with the same token, or otherwise at the beginning, instead of
> +       at the end, of all the trailers.
> +
> +trailer.<token>.ifexist::
> +       This option makes it possible to chose what action will be
s/chose/choose/
Show 24 quoted lines
> +       performed when there is already at least one trailer with the
> +       same token in the message.
> ++
> +The valid values for this option are: `addIfDifferent` (this is the
> +default), `addIfDifferentNeighbor`, `add`, `overwrite` or `doNothing`.
> ++
> +With `addIfDifferent`, a new trailer will be added only if no trailer
> +with the same (token, value) pair is already in the message.
> ++
> +With `addIfDifferentNeighbor`, a new trailer will be added only if no
> +trailer with the same (token, value) pair is above or below the line
> +where the new trailer will be added.
> ++
> +With `add`, a new trailer will be added, even if some trailers with
> +the same (token, value) pair are already in the message.
> ++
> +With `overwrite`, the new trailer will overwrite an existing trailer
> +with the same token.
> ++
> +With `doNothing`, nothing will be done, that is no new trailer will be
> +added if there is already one with the same token in the message.
> +
> +trailer.<token>.ifmissing::
> +       This option makes it possible to chose what action will be
s/chose/choose/
Show 18 quoted lines
> +       performed when there is not yet any trailer with the same
> +       token in the message.
> ++
> +The valid values for this option are: `add` (this is the default) and
> +`doNothing`.
> ++
> +With `add`, a new trailer will be added.
> ++
> +With `doNothing`, nothing will be done.
> +
> +trailer.<token>.command::
> +       This option can be used to specify a shell command that will
> +       be used to automatically add or modify a trailer with the
> +       specified 'token'.
> ++
> +When this option is specified, it is like if a special 'token=value'
> +argument is added at the end of the command line, where 'value' will
> +be given by the standard output of the specified command.

What happens if the text returned by the command has multiple lines? Should the documentation say something about this?

Show 17 quoted lines
> +If the command contains the `$ARG` string, this string will be
> +replaced with the 'value' part of an existing trailer with the same
> +token, if any, before the command is launched.
> ++
> +The following environment variables are set when the command is run:
> +GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME,
> +GIT_COMMITTER_EMAIL.
> +
> +SEE ALSO
> +--------
> +linkgit:git-commit[1]
> +
> +GIT
> +---
> +Part of the linkgit:git[1] suite
> --
> 1.8.5.2.201.gacc5987
Previous: Christian CouderNext: Christian Couder
Message 19 of 26 in “Add interpret-trailers builtin”
  1. 00/17 Add interpret-trailers builtinChristian Couder, Jan 26, 2014
  2. 01/17 Add data structures and basic functions for commit trailersChristian Couder, Jan 26, 2014
  3. 02/17 trailer: process trailers from file and argumentsChristian Couder, Jan 26, 2014
  4. 03/17 trailer: read and process config informationChristian Couder, Jan 26, 2014
  5. 04/17 trailer: process command line trailer argumentsChristian Couder, Jan 26, 2014
  6. 05/17 strbuf: add strbuf_isspace()Christian Couder, Jan 26, 2014
  7. 06/17 trailer: parse trailers from input fileChristian Couder, Jan 26, 2014
  8. 07/17 trailer: put all the processing together and printChristian Couder, Jan 26, 2014
  9. 08/17 trailer: add interpret-trailers commandChristian Couder, Jan 26, 2014
  10. 09/17 trailer: add tests for "git interpret-trailers"Christian Couder, Jan 26, 2014
  11. 10/17 trailer: if no input file is passed, read from stdinChristian Couder, Jan 26, 2014
  12. 11/17 trailer: add new_trailer_item() functionChristian Couder, Jan 26, 2014
  13. 12/17 strbuf: add strbuf_replace()Christian Couder, Jan 26, 2014
  14. 13/17 trailer: execute command from 'trailer.<name>.command'Christian Couder, Jan 26, 2014
  15. 14/17 trailer: add tests for trailer commandChristian Couder, Jan 26, 2014
  16. 15/17 trailer: set author and committer env variablesChristian Couder, Jan 26, 2014
  17. 16/17 trailer: add tests for commands using env variablesChristian Couder, Jan 26, 2014
  18. 17/17 Documentation: add documentation for 'git interpret-trailers'Christian Couder, Jan 26, 2014
  19. Eric SunshineJan 27, 2014
  20. Christian CouderJan 27, 2014
  21. Junio C HamanoJan 27, 2014
  22. Christian CouderJan 29, 2014
  23. Junio C HamanoJan 29, 2014
  24. Eric SunshineFeb 2, 2014
  25. Junio C HamanoJan 27, 2014
  26. Christian CouderJan 29, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.