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

[ZheNing Hu <adlternative@gmail.com>]

Junio C Hamano <gitster@pobox.com> 于2021年4月14日周三 上午3:18写道：
>
> ZheNing Hu <adlternative@gmail.com> writes:
>
> >> 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.
> >>
> >
> > If i'm not wrong, Christan meant that this command must run so it's
> > "consistency", and Junio thinks this "consistency" is not needed.
>
> My stance actually is a bit stronger than that.  I suspect that
> running the command without argument once even when no --trailer on
> the command line asks for that <key> is a misfeature, if not a bug
> (only because it is now documented by 1/2 as such---before that, at
> least I did not read the document that way).  And unless it is shown
> that it is not a misfeature but is a useful behaviour with an example
> use case that benefits from it, I would prefer not to replicate it
> in the ".cmd".
>
> > It is true that there is not much harm in keeping `.cmd` at the behavior
> > of `.command` now.
>
> It is far from "there is not much harm".  It misses the whole point
> of the exercise.
>
> Only replacing the first occurrence and not the second and
> subsequent occurrence is not what we are keeping in ".cmd".
>
> Replacing in an unsafe way with respect to the command line syntax
> is not what we are keeping in ".cmd".
>
> That is because these two are misfeatures if not bugs (only because
> they are documented).
>
> In fact, the only reason why we are introducing .cmd is so that we
> can deprecate .command and get rid of its misfeatures while keeping
> only good bits.
>
> So I am waiting to hear why it is not a misfeature.  If it is not,
> then surely I am fine to keep it for now and add a workaround later,
> but until that happens, I do not think "commit --trailer" can be
> used as a way to allow end-users emulate "-s" for their favorite
> trailer like helped-by, acked-by, etc.
>

If it is really necessary to solve this "empty execution" in .cmd,
Maybe we need to consider two points:
* Do we need a new config flag as you said `[implicitExecution = false]`
or just drop it? Has anyone been relying on the "empty execution" of
.command before? This may be worthy of concern.
*  Do we need `trailer.<token>.runMode` as Christan said before?
I rejected his this suggestion before, and now I regret it a bit.

--
ZheNing Hu