Re: Questions about trailer configuration semantics

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 27, 2020, 20:11 UTC
Message-ID: <xmqqk0yog1lg.fsf@gitster.c.googlers.com>
In-Reply-To: <CAP8UFD1XV_jN10yOc2o4=5PtPcvT-RbxhY1H3swZz2r4g-Uzkw@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 17 quoted lines

>> >  $ printf '\naCKed: Zz\n' | \
>> >    git -c 'trailer.Acked.key=Acked' interpret-trailers --parse
>> >  will emit: "Acked: Zz"
>
> Yeah, I think that's nice, as it can make sure that the key appears in
> the same way. It's true that it would be better if it would be
> documented.
>
>> > but only if "key" is used, other config options doesn't cause it to be
>> > normalized.
>> > E.g:
>> >  $ printf '\naCKed: Zz\n' | \
>> >    git -c 'trailer.Acked.ifmissing=doNothing' interpret-trailers --parse
>> >  will emit: "aCKed: Zz" (still lowercase a and uppercase CK)
>
> Yeah, in this case we are not sure if "Acked" or "aCKed" is the right
> way to spell it.

OK, so in short, the trailer subsystem matches the second level of the configuration variable name (e.g. "Acked") in a case insensitive way, and it does *not* normalize the case in the output. The .key request is a mechanism to replace the matched key with the specified string, so there is *NO* case normalization in what Anders observed.

In other words,

  $ printf '\naCKed: Zz\n' | \
    git -c 'trailer.Acked.key=Rejected' interpret-trailers --parse

would have emitted "Rejected: Zz".