git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>, Johan Herland <johan@herland.net>,
	Josh Triplett <josh@joshtriplett.org>,
	Thomas Rast <tr@thomasrast.ch>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Greg Kroah-Hartman <greg@kroah.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v3 17/17] Documentation: add documentation for 'git interpret-trailers'
Date: Sun, 26 Jan 2014 19:52:59 -0500	[thread overview]
Message-ID: <CAPig+cQgq_2h+n8OeDsrmk_NqAA4RDNzkBAtNCNjOAGMrFN4jg@mail.gmail.com> (raw)
In-Reply-To: <20140126170011.24291.26146.chriscool@tuxfamily.org>

On Sun, Jan 26, 2014 at 12:00 PM, Christian Couder
<chriscool@tuxfamily.org> wrote:
> 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/

> +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".

> +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...".

> +'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/

> +       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/

> +       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/

> +       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?

> +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

  reply	other threads:[~2014-01-27  0:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-26 16:59 [PATCH v3 00/17] Add interpret-trailers builtin Christian Couder
2014-01-26 16:59 ` [PATCH v3 01/17] Add data structures and basic functions for commit trailers Christian Couder
2014-01-26 16:59 ` [PATCH v3 02/17] trailer: process trailers from file and arguments Christian Couder
2014-01-26 16:59 ` [PATCH v3 03/17] trailer: read and process config information Christian Couder
2014-01-26 16:59 ` [PATCH v3 04/17] trailer: process command line trailer arguments Christian Couder
2014-01-26 16:59 ` [PATCH v3 05/17] strbuf: add strbuf_isspace() Christian Couder
2014-01-26 16:59 ` [PATCH v3 06/17] trailer: parse trailers from input file Christian Couder
2014-01-26 17:00 ` [PATCH v3 07/17] trailer: put all the processing together and print Christian Couder
2014-01-26 17:00 ` [PATCH v3 08/17] trailer: add interpret-trailers command Christian Couder
2014-01-26 17:00 ` [PATCH v3 09/17] trailer: add tests for "git interpret-trailers" Christian Couder
2014-01-26 17:00 ` [PATCH v3 10/17] trailer: if no input file is passed, read from stdin Christian Couder
2014-01-26 17:00 ` [PATCH v3 11/17] trailer: add new_trailer_item() function Christian Couder
2014-01-26 17:00 ` [PATCH v3 12/17] strbuf: add strbuf_replace() Christian Couder
2014-01-26 17:00 ` [PATCH v3 13/17] trailer: execute command from 'trailer.<name>.command' Christian Couder
2014-01-26 17:00 ` [PATCH v3 14/17] trailer: add tests for trailer command Christian Couder
2014-01-26 17:00 ` [PATCH v3 15/17] trailer: set author and committer env variables Christian Couder
2014-01-26 17:00 ` [PATCH v3 16/17] trailer: add tests for commands using " Christian Couder
2014-01-26 17:00 ` [PATCH v3 17/17] Documentation: add documentation for 'git interpret-trailers' Christian Couder
2014-01-27  0:52   ` Eric Sunshine [this message]
2014-01-27 20:33     ` Christian Couder
2014-01-27 21:20       ` Junio C Hamano
2014-01-29 20:01         ` Christian Couder
2014-01-29 20:30           ` Junio C Hamano
2014-02-02 11:22       ` Eric Sunshine
2014-01-27 21:05 ` [PATCH v3 00/17] Add interpret-trailers builtin Junio C Hamano
2014-01-29 19:27   ` Christian Couder

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=CAPig+cQgq_2h+n8OeDsrmk_NqAA4RDNzkBAtNCNjOAGMrFN4jg@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=chriscool@tuxfamily.org \
    --cc=dan.carpenter@oracle.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=greg@kroah.com \
    --cc=johan@herland.net \
    --cc=josh@joshtriplett.org \
    --cc=mhagger@alum.mit.edu \
    --cc=peff@peff.net \
    --cc=tr@thomasrast.ch \
    /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;
as well as URLs for NNTP newsgroup(s).