On Sat, 2007-10-13 at 01:46 +0100, Johannes Schindelin wrote:
> Jakub, thank you very much for doing this. It is a very tedious work, and
> I deem it invaluable.
Seconded! This survey is very valuable, Jakub!
> > Figure out why people find git hard to learn and eliminate those
> > barriers to entry. Make git more task-oriented rather than
> > data-model-oriented the way it is now.
>
> Frankly, expectations like these make me want to bang somebody's head on
> the wall. Why do people expect others to work for them for free? Hard?
The "barriers to entry" / "data model" comment came from me :)
"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. 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".
"Make git more task-oriented rather than data-model-oriented" is about
making the tool adapt to what you usually want to do, instead of making
*you* adapt to the way the tool wants to work. Many commands in Git
have documentation like
"option --foo updates the refs without modifying the index. Requires
a clean working tree"
This is gibberish for people who are not very familiar with Git's
internals. "Git for computer scientists" provides a *very nice*
explanation of the DAG and refs and tags, but unfortunately it doesn't
explain the index, why you would want to know about it, etc.
Git introduces a lot of terminlogy: refs, index, working tree, remotes,
origin, HEAD (which is not the same as CVS HEAD!), detached head,
rebasing, porcelains, etc. Even the basic documentation is hard to read
when you don't know all the terms yet.
It's nice that Git lets you manipulate the repository in all kinds of
ways, but presenting porcelains at the same level as plumbing makes
things hard for users to learn. I was just in our Beijing office,
teaching people about development tools and Git in particular.
Federico: "get Git from this location"
Beijing hacker: tap tap tap, "okay, it's installed now"
Federico "Git commands all start with 'git'"
Beijing hacker: git<Tab>
Bash: Display all 150 possibilities?
Beijing hacker: "oh, shit..."
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.
Federico
-
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
