Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'

From: Johan Herland <johan@herland.net>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Christian Couder <chriscool@tuxfamily.org>,
	Christian Couder <christian.couder@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git mailing list <git@vger.kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Thomas Rast <tr@thomasrast.ch>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Greg Kroah-Hartman <greg@kroah.com>, Jeff King <peff@peff.net>,
	Eric Sunshine <sunshine@sunshineco.com>,
	ramsay@ramsay1.demon.co.uk, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
Date: Tue, 27 May 2014 11:17:52 +0200	[thread overview]
Message-ID: <CALKQrgdMxCP8e+6wJugnJUhLfHvf-t9MDPqdiZvc+HQc+GcBiQ@mail.gmail.com> (raw)
In-Reply-To: <53844AEF.1080502@alum.mit.edu>

On Tue, May 27, 2014 at 10:21 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> tl;dr: This patch series wants to introduce a permanent new Git data
> format.  The current version can write trailers in formats that it is
> incapable of reading, which I consider broken.  I advocate a stricter
> specification of the format of trailers, at least until we get feedback
> from users that they need more flexibility.
>
> On 05/25/2014 10:37 AM, Christian Couder wrote:

[...]

>> My opinion is that many Git developers have been engaged and you can
>> see that in the Cc.
>>
>> I cannot tell if they are all very happy or not but I suppose that if
>> they were very unhappy they would tell it.
>> [...]
>
> It was unfair of me to try to characterize the opinions of other
> developers.  On the other hand, even though many people have commented
> on this proposal over its long lifetime, I didn't get the feeling that
> it has won a consensus of +1s in its current form.
>
> I'd love to hear the opinion of others because maybe I'm totally out in
> left field.

FWIW, after a quick read, I find myself agreeing very much with
Michael's arguments for a stricter format (at least in its initial
version).

We are formalizing and applying tools/automation to a part of the
commit message that has so far been ad hoc and very informal. There is
no expectation that _every_ _single_ existing use of (informal)
trailers (except the somewhat-formalized support for --signoff) must
be supported by git-interpret-trailers.

However, there _is_ an expectation that git-interpret-trailers is
self-consistent and does not stumble over its own trailers. Therefore,
it makes perfect sense to make v1 very strict in what formats it
produce (i.e. a strict "key: value" format is enough for now).

> And I want to reiterate that the reason I'm so emphatic about this
> proposal is because I think it will be such a great new feature.  I just
> think that some tweaks would make it a more solid foundation for
> building even more functionality onto.

Fully agreed. git-interpret-trailers have come up in several other
discussion, both on the git mailing list and elsewhere, and I have no
doubt that this will be a very useful feature that will be put to good
use in many projects.

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net