can you elaborate on why you think git is hard?

In my opinion, it's hard because git isn't a VCS, it's a loosely-related bunch of commands to manipulate the on-disk format of a VCS.

Its commands are, conceptually, tools to perform operations on the repo, rather than tools to version your code.

I think the main reason git is hard is many of the most common commands do too many things. For example, the reset command "reset the current HEAD to a specified state" is too general. I don't think most people consider HEAD as both a working directory and a pointer to the current commit in the repository, instead they just think of it as a pointer to the current commit you are working off of. So they start by just memorizing a couple of commands that do what they need to.

reset -- file #unstage a file reset --hard #reset everything in the working directory

Later they might learn to use reset to undo the last commit.

reset --hard HEAD~1

But they probably still don't really understand what the reset command does. I consider it to be an overloaded command. There should be a command to unstage files, a command to move the HEAD of the current branch (which can keep the --hard and --soft options), and a command to just clear everything from the stage/working directory to start over.

Other commands are similarly overloaded which makes it hard for users to understand unless they learn the internals of git.

Git is basically 1000 different programs embedded in both an application and network programming framework.

Each program is also effectively developed independently such that one does not operate the way another does. So there are several learning curves: the one to understand the framework, and the one to understand each program, and then the one to understand how each program inter-operates with others.

Some people "pick it up" without difficulty, but it's because those people don't have to swallow the entire operational knowledge at once. To really grok how anything works you have to learn it from the ground up, instead of task by task. Git is the most convoluted open source project I have ever encountered (from a user's perspective).

imo git is hard, because it is hard to think of history as a tree. also, problems we solve with git are harder than what we used to solve with subversion or cvs. i mean, most of the git problems i or my colleagues ever encountered happened because of a rebase, or rebase + merge, or merge + rebase, or similar combinations, when we tried to rewrite history to make it clean and readable, and we never even think about "clean history" back then.

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

I don't think it is hard to think of history as a tree. SCM tools have been doing that for decades (with fewer branches)

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?)

index and staging area refer to the same thing. The staging area is a high-level concept, while index is more of an implementation detail (exists in .git/index).

The rule of thumb is to only use rebase for local commits (commits that haven't been pushed). This causes pain if people have commited, or will commit, work on a branch that has been rebased remotely.

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).

What do you have if you have several lists with a common ancestor? You have a tree!

I wasn't disagreeing, I simply said I never looked at git's history in that way. While I certainly do have a tree, I don't necessarily perceive it as such, especially when using "git log --graph --format=oneline --first-parent"