Also, git history is more like a DAG.

Also, about that 'grasping in about an hour': way too often, reading some more confuses the hell out of you again. Witness:

You can grasp in about an hour concepts like "index", "staging area" and other that the article mentions.

So, is there a difference between index and staging area? Google "git index vs staging area" gives me top hit http://stackoverflow.com/questions/12138207/is-the-git-stagi..., which does not help me.

Second hit is http://stackoverflow.com/questions/4084921/what-does-the-git.... Again, far from a clear answer.

Further googling/clicking gets me to http://stackoverflow.com/questions/6716355/why-staging-direc....

And no, the git-scm book at http://git-scm.com/documentation did not help _me_ either. It seems to have banned the use of 'index' as the (almost? More or less?) synonym for staging area.

I think a large part of complaints about git are caused by its confusing user interface and confusing terminology. Yes, terminology may have been cleaned up officially, but 'the Internet' is littered with remnants of its history.

Apart from that, one thing that I find confusing about the staging area is that it is invisible. Consequently, there doesn't seem to be a way to build what would get committed on as 'git commit' (do a 'git add X', then edit X. 'git commit' will commit the old content of X, but 'make' will use the edited content of X. Or am I confused again?)

I've never really thought of Git history as a tree. I just think of it as a linked list of commits, and that I have more than one list available (branches).