Re: [PATCH v10 2/2] [GSOC] trailer: add new .cmd config option

From: ZheNing Hu <adlternative@gmail.com>
Date: Apr 17, 2021, 07:41 UTC
Message-ID: <CAOLTT8S-CLSk6Obu-8L+QKb9YjBufVTMcTnSrfaUOQmyej59TQ@mail.gmail.com>
In-Reply-To: <xmqqlf9hinuw.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> 于2021年4月17日周六 上午11:36写道：

Show 34 quoted lines

>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > And continuing this line of thought, I think it would be a perfectly
> > fine extension to allow the script/program that is launched by the
> > .command or .cmd mechanism to signal interpret-trailers that it does
> > not want it to add a trailer as the result of this invocation by
> > exiting with non-zero.  And that would be a reasonable way forward
> > without having to add yet another ugly workaround .runMode.
> >
> > For example, trailer.signoff.cmd could be this script:
> >
> >       #!/bin/sh
> >       if test $# != 1
> >       then
> >               exit 1
> >       else
> >               git log -1 --author="$1" --format='"%aN" <$aE>'
> >       fi
> >
> > where the "implicit" invocation is signalled by not passing any
> > argument, to which the script reacts by exiting with 1, and the
> > interpret-trailers would discard the result of the unasked-for
> > invocation.
>
> The beauty of this approach, compared to say .runMode, is that the
> program specified by .cmd (and .command, except that it cannot tell
> if the invocation is in response to explicit --trailer=<key>:<value>
> request, or the extra one that is done even without being asked)
> have even better control in squelching the trailer output.  Not just
> to silence the extra unasked-for invocation, it can inspect the
> value given to each of --trailer=<key>:<value> option and decide not
> to add a trailer in response to it.
>

If I understand correctly, Your approach may be like this:

First, Those `<token> <value>` pairs we passed on the command line will use one positional parameter in the shell-script.

Second, if it is the trailer implicitly added, originally it was `<token> ""`, now we turn it to `<token> NULL`, This will make the shell-script not pass positional parameters.

Then our shell script can distinguish them by the value of $#.

If we want shell-script to execute implicitly anyway, We can do nothing. the shell-script can be like as Christian mention:

#!/bin/sh echo "$(git config user.name) <$(git config user.email)>"

But If we want shell-script to reject implicit execution, We can judge the value of $# : 0 exit , 1 normal as you mention:

#!/bin/sh
if test $# != 1
then
    exit 0
else
    git log -1 --author="$1" --format='%aN <%aE>'
fi

I agree with your approach. But when I am reproducing your solution, I may be in trouble: If we let shell-script `exit(1)`, `capture_command()` will output "running trailer command '%s' failed" which is its origin strategy in order to catch the user's command error.

But If we use `exit(0)` , The headache is coming again:

Signed-off-by:

the empty value trailer still output. What we want is that those "<token> NULL" are rejected here, we don’t want any other output, do we?

Thanks. -- ZheNing Hu