Christian Couder <> writes:

> From: Junio C Hamano <>
>> Christian Couder <> 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 <>
>> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to