"ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> @@ -252,6 +252,16 @@ also be executed for each of these arguments. And the <value> part of
> these arguments, if any, will be used to replace the `$ARG` string in
> the command.
>
> +trailer.<token>.cmd::
> + The command specified by this configuration variable is run
> + with a single parameter, which is the <value> part of an
> + existing trailer with the same <token>. The output from the
> + command is then used as the value for the <token> in the
> + resulting trailer.
> + The command is expected to replace `trailer.<token>.cmd`.
> + When both .cmd and .command are given for the same <token>,
> + .cmd is used and .command is ignored.
Christian, because ".cmd" is trying to eventually replace it, I find
it a bit disturbing that the description we give here looks a lot
smaller compared to the one for ".command". I am afraid that we may
have failed to reproduce something important from the description of
the ".command" for the above; care to rend a hand or two here to
complete the description?
As I cannot grok what the description for ".command" is trying to
say, especially around this part:
When this option is specified, the behavior is as if a special
'<token>=<value>' argument were added at the beginning of the command
line, where <value> is ...
and
If some '<token>=<value>' arguments are also passed on the command
line, when a 'trailer.<token>.command' is configured, the command will
also be executed for each of these arguments.
I cannot quite judge if what we came up with in the above
description is sufficient.
> -* Configure a 'sign' trailer with a command to automatically add a
> +* Configure a 'sign' trailer with a cmd to automatically add a
> 'Signed-off-by: ' with the author information only if there is no
> 'Signed-off-by: ' already, and show how it works:
> +
> @@ -309,7 +319,7 @@ $ git interpret-trailers --trailer 'Cc: Alice <alice@xxxxxxxxxxx>' --trailer 'Re
> $ git config trailer.sign.key "Signed-off-by: "
> $ git config trailer.sign.ifmissing add
> $ git config trailer.sign.ifexists doNothing
> -$ git config trailer.sign.command 'echo "$(git config user.name) <$(git config user.email)>"'
> +$ git config trailer.sign.cmd 'echo "$(git config user.name) <$(git config user.email)>"'
> $ git interpret-trailers <<EOF
> > EOF
This change would definitely be needed when the support for
".command" is removed after deprecation period. As it does not take
any argument, .cmd and .command should behave identically, so making
this change now, without waiting, may make sense.
> @@ -333,14 +343,14 @@ subject
> Fix #42
> ------------
>
> -* Configure a 'see' trailer with a command to show the subject of a
> +* Configure a 'see' trailer with a cmd to show the subject of a
> commit that is related, and show how it works:
> +
> ------------
> $ git config trailer.see.key "See-also: "
> $ git config trailer.see.ifExists "replace"
> $ git config trailer.see.ifMissing "doNothing"
> -$ git config trailer.see.command "git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \$ARG"
> +$ git config trailer.see.cmd "test -n \"\$1\" && git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \"\$1\"|| true "
> $ git interpret-trailers <<EOF
> > subject
This, too, but until ".command" is removed, wouldn't it be better
for readers to keep both variants, as the distinction between $ARG
and $1 needs to be illustrated?
Besides, the examples given here are not equivalent. The original
assumes that ARG is there, or it is OK to default to HEAD; the new
one gives no output when $ARG/$1 is not supplied. It would confuse
readers to give two too-similar-but-subtly-different examles, as
they will be forced to wonder if the difference is something needed
to transition from .command to .cmd (and I am guessing that it is
not).
Rewriting both to use "--pretty=reference" may be worth doing. As
can be seen in these examples:
git show -s --pretty=reference \$1
git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \$1
that it makes the result much easier to read.
Thanks. Do not send a reroll prematurely; I want to see area
expert's input at this point.
