ZheNing Hu <adlternative@xxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> 于2021年4月15日周四 上午4:33写道：
>>
>> 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).
> ...
> Perhaps such a modification can meet our temporary needs!
>
> @@ -721,9 +738,10 @@ static void process_command_line_args(struct
> list_head *arg_head,
> char *cl_separators = xstrfmt("=%s", separators);
>
> /* Add an arg item for each configured trailer with a command */
> list_for_each(pos, &conf_head) {
> item = list_entry(pos, struct arg_item, list);
> - if (item->conf.cmd || item->conf.command)
> + if (item->conf.command)
>
> I'm so busy today that I probably haven't had time to put this into a
> patch today,
> If this solution is reasonable, I will send a new version of the patch tomorrow.
> As you said, first solve the misfeature, and we can add [trailer.runMode] later.
I am perfectly fine (or rather I'd be happy) to wait for a while to
see such a patch, as it would be a good idea to give time to those
who do have need for this extra/empty execution to chime in. So,
there is no need to rush.
Thanks.
