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

[Junio C Hamano <gitster@pobox.com>]

ZheNing Hu <adlternative@gmail.com> writes:

>> 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.

Yes, if it is useful sometimes to run the .command or .cmd with
empty <value> even when nobody asks for it on the command line with
a "--trailer=<key>:<value>" option, then I agree that the users
should be able to choose between running and not running [*].

> *  Do we need `trailer.<token>.runMode` as Christan said before?
> I rejected his this suggestion before, and now I regret it a bit.

So far, I haven't heard anything that indicates it is a useful
behaviour for .command, so my preference is to get rid of the
behaviour when we introduce .cmd to deprecate .command; yes, until
we get rid of .command, the behaviour between the two would be
inconsistent but that is unavoidable when making a bugfix that is
backward incompatible.

When (and only when) anybody finds a credible use case, we can add a
mechanism to optionally turn it on (e.g. .runMode).

That is my thinking right at this moment, but that's of course
subject to change when a use case that would be helped by having
this extra execution.


[Footnote]

* Right now, all I know is that not being able to turn it off makes
  it impossible to use "git commit --trailer" as a more general
  substitute for "git commit --signoff" without breaking other
  trailers (e.g. --trim-empty may get rid of the result of the extra
  execution, but would remove other trailers that can be
  legitimately empty).  And making it on by default with
  configuration would mean that even though we designed .cmd as a
  better version of the .command feature with its misdesign
  corrected, we'd inherit one misdesign from it, which defeats one
  third of the point of introducing the .cmd in the first place ;-)