El 17/12/2007, a las 13:55, Johannes Schindelin escribió:
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
