A version control system with the feature set git has is necessarily complicated, this is not a bad thing. Forcing the complexity on the user is a bad thing, but git does not do this except when it is necessary to. Using git at a basic level is not hard.

This essay is not attempting to explain how to use git, it is explaining how git itself works and how changes are physically tracked. There's no need for a basic user to know this information, but if someone wants to dig into git and understand how it works, this essay is a nice guide. Explaining how SVN or any other version control system works at this level of detail would also be complicated.

Git isn't exactly a startup (or a company, or even a product), nor did it ever intend to be.

Lots of great software happens to be difficult for a lot of people to intuitively understand.

> "Lots of great software happens to be difficult for a lot of people to intuitively understand."

For real. Maybe it is just me, but I find programs like Photoshop and nearly every CAD program I've ever encountered to be bewilderingly complicated. I don't use any of those sorts of software professionally, but have found myself needing them numerous times for hobby reasons. Every time I try to learn them I become frustrated with just how steep and tall the learning curves are.

Git though? I felt pretty confident with how it worked and basic command line operation after just a weekend.

Maybe git's command line is more inconsistent than hg's or subversions', but in the grand scheme of software difficulty? I just don't get the complaints. "Incomprehensible"? Give me a break. It does not hold a candle to most commercial professional software.

You are not required to understand this concept. But if you're working on a large team and your branch history gets this complicated, you can still effectively use git to manage it. Try that with less-popular version control systems. (Mercurial comes to mind, actually.)

What is it that you can do in git, that you can't do in Mercurial?

I believe one piece still missing is the full functionality provided by the index in Git. There is the record extension, but IIRC that doesn't emulate one of the index's greatest features: during a merge/rebase, non-conflicting changes are already staged, so "git diff" shows only conflicts (and "git diff --cached" shows those changes that merged successfully).

Mercurial does this, and you only have to manually resolve conflicting changes during a merge/rebase. See here

http://mercurial.selenic.com/wiki/MergeToolConfiguration

I think you might have tried this on a instance of Mercurial where the "premerge" option of the merge tool has been turned off for some reason..

Git won because of Github, it's an unpopular opinion but I stand by it. If Github did not exist, Git wouldn't have been adopted by so many projects.

> Git won because of Github, it's an unpopular opinion but I stand by it.

Quite often you will find the exact opposite statement: Github succeeded because it rode on the success of Git.

I'm not saying your position is wrong, but they cannot both be right.

Sometimes technical things are complicated, because people don't work or communicate in tidy ways.

You could make similar complaints about many of the foundations that make technology possible. Take for example a protocol that enabled you to read this message: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#/...

So by your logic, we shouldn't have helicopters? Using them arguably requires a lot more understanding of complicated things than git does.