Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > From: Junio C Hamano <gitster@xxxxxxxxx> >> >> Christian Couder <chriscool@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> >> >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html