Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 28, 2014, 16:37 UTC
- Message-ID
- <xmqq8uqptno9.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20140425.215619.2296838250398594645.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
Show 34 quoted lines
> 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).
Show 18 quoted lines
> 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.