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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 2, 2010, 21:28 UTC
Message-ID: <7vsk2wk8lc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqtyncdeuc.fsf@bauges.imag.fr>

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

Show 19 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> The patch overall looks good, and this comments illustrates the issue
>> rather well.  When the user wants to use "--longopt val" syntax, s/he
>> needs to know that "--longopt" will always take a value.  Arguably
>> majority of options that can take value will, but like "--stat X,Y" this
>> leaves things inconsistent.  Without "--longopt value" patch there won't
>> be such an inconsistency, but I think this patch series is lessor of two
>> evils.
>
> ... 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.

>> Don't you by the way regret the naming of the parsing function by now?
>> There is nothing "diff" about it anymore.
>
> Right. I'll rename them to "parse_long_opt".

Thanks.