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:57 UTC
Message-ID: <ECF98EB9-DE57-4DFF-9F5B-A7FEC3BEB022@wincent.com>
In-Reply-To: <Pine.LNX.4.64.0712171328020.9446@racer.site>

El 17/12/2007, a las 14:30, Johannes Schindelin escribió:

Show 18 quoted lines

>> 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.
>
> My reasoning is like as for "-p".  "--bare" is not special to  
> "init".  It
> makes git not guess, but work on the current directory as a bare
> repository.

Yes, I know what --bare does. It seems to me your argument is as follows:

- "git subcommand" is actually "git" (which does setup) followed by  
"git-subcommand" (which performs an action)[*]

- the newcomer should be taught this, and know which options go  
between "git" and "subcommand" and which options go after

- even though there is a straightforward way to have "git subcommand  
specials args" work without breaking compatibility, you oppose it on  
the grounds that users should know how Git works

- the fact that CVS also has some options that go before the  
subcommand makes it OK for git to do the same

- even though we could have a better UI that didn't require any of  
this explanation at all, we should keep the UI we have seeing as it is  
easy to explain

And possibly some combination of these two as well:

- requiring arguments to be inserted between "git" and "subcommand"  
doesn't undermine the effort to make git appear like a single tool to  
users

- the effort to move to dashless forms has nothing to do with  
presenting git as a single tool to users

Well, I basically disagree with you on most of these points; all but the first one(*), really. I think it's fairly clear what both you and I think on this and I'm not very interested in debating it further; I am more interested in hearing other people's points on this to get a feeling for whether there is a consensus (or lack thereof).

Cheers, Wincent