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

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <chriscool@tuxfamily.org> writes:

> From: Junio C Hamano <gitster@pobox.com>
>>
>> Christian Couder <chriscool@tuxfamily.org> writes:
>> ...
>
>>> +	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.
>> 
>> I assume that this is for things like
>> 
>> 	bug #538
>> 
>> and the configuration would say something like:
>> 
>> 	[trailer "bug"]
>>         	key = "bug #"
>> 
>> For completeness (of this example), the bog-standard s-o-b would
>> look like
>> 
>> 	Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>> 
>> and the configuration for it that spell the redundant "key" would
>> be:
>> 
>> 	[trailer "Signed-off-by"]
>>         	key = "Signed-off-by: "
>
> Yeah, but you can use the following instead:
>
>  	[trailer "s-o-b"]
>          	key = "Signed-off-by: "

Sure, but note that both of these have a SP at the end in the value
part (which I think is a sensible thing to do).

> The <token> and the key can be different.
>
>> Am I reading the intention correctly?
>
> Yeah, I think so.
>
>> That is, when trailer.<token>.key is not defined, the value defaults
>> to "<token>: " (with one SP after the label and colon),
>
> Yes.
>
>> and when it
>> is defined, the value can come directly after it.
>
> The value can come directly after the key, only if the key ends with '#'.
>
> If it ends with something else, except spaces, one SP will be added
> between the key and the value.

And I do not think we want (or even need) this "only when it ends
with #" special casing in the code at all.  When the project's
convention is to say "frotz# value-of-frotz", the users will specify
that with 'key = "frotz# "' (with a trailing SP in the value part),
and in a project that wants 'nitfol %value-of-nitfol', your parser
will find 'key = "nitfol %"'.  The users will obtain the result they
want for either case, and a hard-coded special casing in the code
that only has incomplete knowledge on the project convention will
actively harm them.  I'd suggest dropping that special case.