El 17/12/2007, a las 14:30, Johannes Schindelin escribió:
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
-
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
