On Mon, Apr 12, 2021 at 10:51 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > +For consistency, the $1 is also passed, this time with the empty string, > > +in the command when the command is first called to add a trailer with > > +the specified <token>. > > I guess the same question as 1/2 applies to this part. I am not > sure what "consistency" the behaviour of calling the configured > command with no argument is trying to achieve. To me, .cmd doing > this may be for consistency with .command but I am not sure why > the consistency is even desiable. It might be desirable to make it easier for people to migrate from ".command" to ".cmd". I agree this is debatable, but I don't see a big downside in it. Maybe, if no argument was passed at all the first time the command is called instead of the empty string, the command could then know that it's called for the first time. I am not sure this would be very helpful in practice though. > > +$ cat ~/bin/gcount > > +#!/bin/sh > > +test -n "$1" && git shortlog -s --author="$1" HEAD || true > > +$ git config trailer.cnt.key "Commit-count: " > > +$ git config trailer.cnt.ifExists "replace" > > +$ git config trailer.cnt.cmd "~/bin/gcount" > > +$ git interpret-trailers --trailer="cnt:Junio" <<EOF > > +> subject > > +> > > +> message > > +> > > +> EOF > > +subject > > + > > +message > > + > > +Commit-count: 22484 Junio C Hamano > > +------------ > > This and the other (omitted) example demonstrates how the initial > "empty" invocation is useless by using "replace". Which also means > that you cannot add more than one trailer of the same <key> with the > mechanism (since the older ones are replaced with the latest). You can add more than one trailer with the same key if you don't use "replace" but use "--trim-empty" on the command line, so that an empty trailer added by the initial invocation is removed. And we can later add a `trailer.<token>.runMode` to remove the initial invocation. > The code change and the test change are consistent with the design, > though. Yeah, this patch looks good to me now. Thanks!
