All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: 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>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH v12 11/11] Documentation: add documentation for 'git interpret-trailers'
Date: Wed, 28 May 2014 12:44:36 -0700	[thread overview]
Message-ID: <xmqqa9a1d6xn.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140525053223.5329.28002.chriscool@tuxfamily.org> (Christian Couder's message of "Sun, 25 May 2014 07:32:22 +0200")

Christian Couder <chriscool@tuxfamily.org> writes:

> +trailer.<token>.key::
> +	This `key` will be used instead of <token> in the
> +	trailer. After the last alphanumeric character, this variable
> +	can contain some non alphanumeric characters, like for example
> +	`'%'` (one percent sign), `' = '` (one space followed by one
> +	equal sign and then one space), `' #'` (one space followed by
> +	one number sign) or even just `' '` (one space), that will be
> +	used to separate the <token> from the <value> in the
> +	trailer. The default separator, `': '` (one colon followed by
> +	one space), which is the usual standard, is added only if the
> +	last character in `key` is alphanumeric, so watch out for
> +	unwanted trailing spaces in this variable.

Perhaps corollary to the other review comment to this patch, I think
this is overly complex without giving more value to the users than
it causes confusion.

If the goal is to allow random syntax on the output side, why do you
even need to list percent, pound, etc., when you can just say "The
key is emitted and then your value" and the user will get exactly
what they specified to be emitted?

Any magic applied on top (namely, we would add ": " only in certain
circumstances) only makes things unnecessarily complex; I think your
having to say "so watch out for..." is a clear indication of that.

If we use the "separator", so that we can recognise a line with an
unseen key as a trailer we do not know about, we should stick to
just a single standard one ':' and I think it is OK to add a missing
": " by magic if that is the direction we are going to take, though.

  parent reply	other threads:[~2014-05-28 19:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25  5:32 [PATCH v12 00/11] Add interpret-trailers builtin Christian Couder
2014-05-25  5:32 ` [PATCH v12 01/11] trailer: add data structures and basic functions Christian Couder
2014-05-25  5:32 ` [PATCH v12 02/11] trailer: process trailers from input message and arguments Christian Couder
2014-05-25  5:32 ` [PATCH v12 03/11] trailer: read and process config information Christian Couder
2014-05-25  5:32 ` [PATCH v12 04/11] trailer: process command line trailer arguments Christian Couder
2014-05-25  5:32 ` [PATCH v12 05/11] trailer: parse trailers from file or stdin Christian Couder
2014-05-25  5:32 ` [PATCH v12 06/11] trailer: put all the processing together and print Christian Couder
2014-05-25  5:32 ` [PATCH v12 07/11] trailer: add interpret-trailers command Christian Couder
2014-05-25  5:32 ` [PATCH v12 08/11] trailer: add tests for "git interpret-trailers" Christian Couder
2014-05-28 19:28   ` Junio C Hamano
2014-05-25  5:32 ` [PATCH v12 09/11] trailer: execute command from 'trailer.<name>.command' Christian Couder
2014-05-25  5:32 ` [PATCH v12 10/11] trailer: add tests for commands in config file Christian Couder
2014-05-25  5:32 ` [PATCH v12 11/11] Documentation: add documentation for 'git interpret-trailers' Christian Couder
2014-05-28 19:35   ` Junio C Hamano
2014-06-29  9:37     ` Christian Couder
2014-06-30  6:40       ` Junio C Hamano
2014-05-28 19:44   ` Junio C Hamano [this message]
2014-06-30 11:57   ` Jakub Narębski
2014-07-01 13:34     ` 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=xmqqa9a1d6xn.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=chriscool@tuxfamily.org \
    --cc=dan.carpenter@oracle.com \
    --cc=git@vger.kernel.org \
    --cc=greg@kroah.com \
    --cc=johan@herland.net \
    --cc=josh@joshtriplett.org \
    --cc=jrnieder@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=peff@peff.net \
    --cc=ramsay@ramsay1.demon.co.uk \
    --cc=sunshine@sunshineco.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.