Re: git.c option parsing

From: Wincent Colaiuta <win@wincent.com>
Date: Dec 17, 2007, 09:01 UTC
Message-ID: <25018761-80E8-410C-BB18-DD799F58308A@wincent.com>
In-Reply-To: <7vsl21aeqw.fsf@gitster.siamese.dyndns.org>

El 17/12/2007, a las 9:48, Junio C Hamano escribió:

Show 19 quoted lines

> Wincent Colaiuta <win@wincent.com> writes:
>
>> Of course, the above plan will only work for builtins, not for
>> scripts. An additional step would be needed to enable scripts to
>> handle these options; perhaps teaching "git rev-parse" something...
>
> As long as special options stay special and we make a rule not to  
> allow
> any subcommand to assign its own meaning to them, the git wrapper can
> lookahead and reorder, when seeing a command line:
>
> 	git scripted-command --special
>
> into
>
> 	git --special scripted-command
>
> And that approach would work well for built-ins as well, I would
> imagine.

Yes, and it would be simpler to implement also. The only downside is that without all the other proposed changes things like "git-dashed -- special" wouldn't work; only teaching the builtins to actually handle the special options would work in that case. And in the interests of consistency I think it's pretty important that "git subcommand -- special" and "git-subcommand --special" both work the same as the user would (reasonably) expect them to...

Show 8 quoted lines

> There is one minor detail, though.  There could be an option-parameter
> that is literally --special.  E.g.
>
> 	git grep -e --no-paginate
>
> should not be reordered to
>
> 	git --no-paginate grep -e

Yes, that's definitely one that would need to be treated as a special case.

Cheers, Wincent