Christian Couder <christian.couder@xxxxxxxxx> writes:
>> > $ 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".
