From: Wincent Colaiuta <win@wincent.com>
Date: Mon, 17 Dec 2007 09:01:56 GMT
Subject: Re: git.c option parsing
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ó:

> 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...

> 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