Re: Hyphens and hiding core commands

On Mon, 27 Nov 2006 15:59:17 -0800, Junio C Hamano wrote:

I tend to disagree.  "This is the easiest way to use, even for
beginners" and "this way should be the default for all levels of
users" are quite different.

I'll gladly agree that different defaults make sense for different
users. Fortunately, we have a config file syntax that allows advanced
users to select the defaults they prefer. But, what should be obvious
is that the config file is not an option available for reducing the
learning curve of git.

Creating a "git cat" and promote that in the Tutorial makes a
lot of sense, but then that can easily be done with aliases ;-).

...

On the other hand, if "cat-file -p" needs to be used often, I think
there is something ELSE that is wrong.

Sure. I don't think "cat-file -p" is any big problem. I only mention
it because it _is_ mentioned in the git tutorial. So, let's add "git
cat" or else find some other way to address what the tutorial is
trying to demonstrate there.

I would not mind if you created "commit-easy" (just like curl
library has curl_x_easy),

Are you really serious about that? I think that's an awful idea.

Interfaces that give longer names to the simpler functionality are
really broken. There are plenty of examples of this kind of thing,
(XCreateWindow and XCreateSimpleWindow), but their existence in no way
justifies this as a good thing.

The git commit syntax already suffers from this, ("commit -a" being a
longer name than its conceptually more complex cousin, "commit"), so
"commit-easy" would only make that problem worse.

                          but the current way the command works
is more useful once you grok the index.  Being able to work in a
slightly dirty tree and commit only the necessary things, and
being able to do so even for a merge commit, is damn convenient.

Sure. You don't need to convert me to that idea. I use that mode
regularly, (though probably not more often than when committing an
index that happens to match my working tree). But my proposal doesn't
remove this functionality at all.

Because there is a learning curve involved, an easier way to use
git without worrying about the index was added in the form of
'-a' for beginners.

Yes, there is a learning curve. There's the "once you grok the index"
stuff you just mentioned. And it's really backwards to have to teach
people that the "basic" way to do something is with a command line
that looks more complex, ("commit -a"), and that "once you learn more
you'll understand what that -a is all about and you'll know when not
to use it".

I've taught lots of people how to use git like that, and it's really
awkward. It would be much easier if learning new concepts and learning
new command-line options were correlated. That would allow whole
concepts to be dropped from the most basic introductions to git.

                     People who use index regularly should not
be forced to spend extra keystrokes for the rest of their lives
only because you want to lose '-a' from the tutorial document.

You said yourself in the "cat-file -p" case, that can be done with
aliases. No extra keystrokes are needed.

And many potential users who are evaluating git compared to other
systems _do_ currently see something that will cost them extra
keystrokes for the rest of their lives. And that is being used as part
of the argument against git in some cases.

Now, maybe that's not the real reason people are rejecting git, but it
sure would be a nice excuse to remove from the potential list of
objections.

The tool should be designed for regular users, not for the first
few pages of the tutorial.

I'm not proposing eliminating the index or anything here. I really
don't see how the default of this one command has any impact at all on
the design of git. It's all still there.

-Carl