Christian Couder <chrisc...@tuxfamily.org> writes:
> From: Junio C Hamano <gits...@pobox.com>
>> Christian Couder <chrisc...@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 <chrisc...@tuxfamily.org>
>> and the configuration for it that spell the redundant "key" would
>> [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),
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html