Re: [PATCH 4/5 v4] log: parse detached options like git log --grep foo

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2010, 17:16 UTC
Message-ID: <7vlj8nipl9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpq8w4ob3yz.fsf@bauges.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 21 quoted lines

>>> ... especially when parse-option already does this:
>>>
>>> git commit --message foo   => works
>>> git gc --prune 'last week' => doesn't
>>>
>>> Just like most GNU tools:
>>>
>>> grep --regexp foo => works
>>> grep --color auto => doesn't
>>
>> Hmm.
>>
>> Are you hinting that we should keep "you can say '-Ofoo' and '-O foo'"
>> bits but we should drop "you can also say '--opt=foo' and '--opt foo' as
>> long as --opt always takes an argument"?
>>
>> I actually think that may make sense.
>
> I'm not sure I parsed your sentence correctly, but if I did, then no,
> I don't think we should drop separate forms when --opt always takes an
> argument, just the opposite.

What I meant was somewhat different. I agree that we _could_ take separate "--opt <string>" form when --opt is known to always take an argument without ambiguity (the same goes for "-O <string>").

But I thought you were suggesting to accept:

    -O<string>
    -O <string>
    --opt=<string>

but never take:

    --opt <string> (even when --opt always takes an argument)

because that would further reduce one source of potential confusion (i.e. the user needs to remember if --opt always takes an argument or not). I thought you mentioned that neither parse-options nor GNU tools take "--prune last", "--color auto" as a good supporting argument for this---the users won't miss the "--opt <string>" feature because that is not a common practice.

And I was agreeing to that.