Re: Questions about trailer configuration semantics
- From
Anders Waldenborg <anders@0x63.nu>
- Date
- Jul 27, 2020, 22:17 UTC
- Message-ID
- <878sf4r4au.fsf@0x63.nu>
- In-Reply-To
- <xmqqk0yog1lg.fsf@gitster.c.googlers.com>
Junio C Hamano writes:
Show 7 quoted lines
> Christian Couder <christian.couder@gmail.com> writes: >> 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
From what I can understand it tries to match *both* on the second level AND the value of .key (trailers.c:token_matches_item)
$ printf '\na: 1\nb: 2\nc: 3\n' | \ git -c 'trailer.A.key=B' interpret-trailers B: 1 B: 2 c: 3
and then uses the .key value when outputting the result (by calling trailer.c:token_from_item)
I.e: it gets "a: 1", tries to find configuration for that, and finds trailer.A because "a" (case insenitively) matches conf.name, therefore it outputs value of trailer.A.key + separator + "1"
then it gets "b: 1", and again finds trailer.A because "b" matches conf.key.
> , 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.
Hmm. Maybe the "matching" vs "outputting" makes it clearer.
Given configuration trailer.<NAME>.key=<KEY>
When printing a parsed trailer, e.g from pretty format "%(trailers)", "git interpret-trailers" passthrough of existing trailers or addition of a new trailer with --trailer: <KEY> is used in output. If <KEY> is not configured the trailer token is output the same way as it was in input.
When finding a trailer, e.g for '--trailer x=y' or trailer.<NAME>.where=before/after: matching is done against both <NAME> and <KEY>.
When showing a single trailer with pretty format '%(trailers:key=X)' it is matched against <KEY> only. (I guess one can see this as matching on the formatted output).
Show 6 quoted lines
> In other words, > > $ printf '\naCKed: Zz\n' | \ > git -c 'trailer.Acked.key=Rejected' interpret-trailers --parse > > would have emitted "Rejected: Zz".
Indeed.