Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
>>> ... 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html