Junio C Hamano writes: > Christian Couder <christian.couder@xxxxxxxxx> 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). > In other words, > > $ printf '\naCKed: Zz\n' | \ > git -c 'trailer.Acked.key=Rejected' interpret-trailers --parse > > would have emitted "Rejected: Zz". Indeed.
