Federico Mena Quintero wrote:
"Find out why people find git hard to learn and eliminate those barriers
to entry" is what we do with usability tests e.g. in GNOME.
And what every major corporation who's serious about UI's do. Windows
works the way it does because that's how idiots expect it to work. Sad but
true. If our aim is world domination, we need not cater to the morons, but
we must make it easier for them to start learning on their own.
You ask
people to use your software to accomplish well-defined tasks ("send a
mail to foo@xxxxxxx", "using the word processor, copy this fancy printed
layout"). Then, you see how they *expect* your software to work, you
see in which places it doesn't behave like that, and you fix it. This
produces very good results. For Git in particular this could be things
like, "Import this project from SVN, fix a bug, commit the patch", or
"You are a maintainer, merge in these two branches from two
contributors".
I like it. So much so that I'll see if I can get a non-programmer at work
to do these tasks. Now... to assemble that task-list. Suggestions welcome.
It's hard to know where to begin :) Do I need "git-cherry-pick" or
"git-cherry"? Why is the "apply a patch" command called "git-am"? Why
is it different from "git-apply"? From "git-applypatch"? Etc.
I agree completely. It wouldn't be hard to make git-apply figure out if
it's being fed something that 'am' would normally want, and if it's being
fed it inside a git repo. If so, make it work just like 'am'.
git-applypatch was deprecated a long time ago and has already been removed.
Personally, I can't help but think that the numerous times I've heard "oh
gods, that's a lot of commands" should finally mean something. I've started
taking a look at which of them one can bundle together. If we can drop the
porcelainish commands down to ~30 or so, and hide the plumbing from git-<tab>
listings, the initial hurdle people have to jump would be significantly lower.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
