Re: [PATCH] Have a flag to stop the option parsing at the first argument.

From: Wincent Colaiuta <win@wincent.com>
Date: Dec 17, 2007, 13:12 UTC
Message-ID: <223E3B44-92DA-4861-83D6-67E56F70E784@wincent.com>
In-Reply-To: <Pine.LNX.4.64.0712171253290.9446@racer.site>

El 17/12/2007, a las 13:55, Johannes Schindelin escribió:

Show 25 quoted lines

> On Mon, 17 Dec 2007, Wincent Colaiuta wrote:
>
>> El 17/12/2007, a las 13:26, Johannes Schindelin escribi?:
>>
>>> I think it is wrong to go out of our way to support "git status - 
>>> p" as
>>> a synonym to "git -p status".  I simply do not believe that  
>>> newcomers
>>> are not intelligent enough to understand that "git -p <subcommand>"
>>> means that the output goes into their pager.
>>
>> But the point is, of all the special options, -p is the *only* that
>> can't unambiguously go after the subcommand.
>
> It should not be put after the subcommand.  That's my point.  Exactly
> because it is -- even conceptually -- no subcommand option.
>
> CVS has many shortcomings, but one lesson here is that people had no
> problems with "cvs -z3 update -d -P".  See, the "-z3" is an option  
> that
> has nothing to do with the subcommand.
>
> Exactly the same situation here.  I never had any problems  
> explaining why
> "-p" goes before the subcommand here.  Never.

Would be even better if there was nothing to explain and it all just worked, which is what I'm proposing here. As I said, -p is the only special option which clashes with any non-special uses.

But leaving -p aside, will you oppose any patches that make it possible for people to write stuff like:

git init --bare

Personally, I think this is an obvious usability improvement worth striving for. Given that "git --bare init" will continue to work under what I'm proposing, I really can't see any worthwhile argument against it. Because we're talking about a UI improvement for newcomers at no cost to old timers.

Cheers, Wincent