Re: [PATCH 1/3] t3650: use option with value consistenly with equal sign

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

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Mon, Mar 23, 2026, at 17:09, Toon Claes wrote:
>> The tests in t3650-replay-basics have mixed use of option arguments
>> with value with and without equal sign. Bring in consistency and use
>> equal sign for all options that expect a value.
>
> If it is about consistency, could you pick one or the other either way
> or go with whatever happened to be most used right now?
>
> Consistency by itself is a weaker argument than arguing that stuck form
> is better for invoking git(1) commands, which is what gitcli(7) argues.
>
> Which is to say: arguing for stuck form in the commit message based on
> it being better is a stronger argument than wanting consistency. :)
>
> Then once one form has been argued for or referenced it follows that you
> should be consistent and use the best approach throughout.
>
>> This makes it easier to distinguish them from positional arguments.
>
> Maybe it’s just me, but sticking with the stuck form makes it harder to
> mess up writing unintended options and positional arguments. Once
> written it might be slightly more readable, but the main benefit is
> using a style that makes messing up harder to pull off.

I am not sure if a patch whose purpose is only to make the CLI
invocation "consistent" is a welcome change, though.  If we support
two forms, exercising both forms and making sure they mean the same
thing may even be better, but short of that, a random mixture of
styles as if end-user human may have picked one form on this day and
the other form on another day may be better than a complete
monoculture.