From: Wincent Colaiuta <win@wincent.com>
Date: Mon, 17 Dec 2007 12:40:18 GMT
Subject: Re: [PATCH] Have a flag to stop the option parsing at the first argument.
Message-ID: <26962818-F702-44D2-BD26-95D74CE21F0D@wincent.com>
In-Reply-To: <Pine.LNX.4.64.0712171223210.9446@racer.site>

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

> Hi,
>
> On Mon, 17 Dec 2007, Wincent Colaiuta wrote:
>
>> Yes, we know what it does because we know that "git ... log ..." is
>> actually two commands and each one handles one of the -p switches,  
>> but
>> it is much easier to present git as a single tool to the newcomer  
>> (and I
>> guess I don't need to argue that case here seeing as the decision has
>> already been taken long ago to talk using dashless forms), and it is
>> much easier to explain to a newcomer something like:
>>
>> git log --paginate -p
>>
>> Than:
>>
>> git -p log -p
>
> How about
>
> 	git log -p
>
> Hmm?
>
> Fact is: you make the tool easier by having sane defaults.  Not by  
> moving
> around command line options.  The option "-p" for git is an option  
> that
> holds for _all_ subcommands.  That's why it belongs _before_ the
> subcommand.
>
>> But it doesn't really matter. The proposed changes allow old-timers  
>> to
>> continue putting their special options between the "git" and the
>> "command". If you don't want to deprecate the -p special because of  
>> the
>> confusion it might cause, I think we should at least not give it a  
>> very
>> prominent place in the documentation, nor use it any examples.
>
> 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.

I'm arguing that the world would be a simpler place, friendlier to  
newcomers if *all* git commands looked like "git subcommand opts...",  
and at the moment -p is the only obstacle to making this so. And just  
in case it's necessary to restate this, I am not proposing removing  
support for the git specials subcommand opts..." form; I'm just trying  
to make it so that we don't have to advertise it so prominently. This  
seems to be the natural complement to the move to dashless forms.

Cheers,
Wincent