1. Not sure his issue here - I count 9 things you need to know for Github (one of which I have never needed to know - treeishes), and 7 things for SVN. It's really not that complex.

2. The command line syntax:

But the shortcut for “git branch” combined with “git checkout”? “git checkout -b”

Indeed. You can branch your code, but not check out the files from the index into the working tree.

Perhaps the confusion here is because the author is coming from an SVN background, where checkout means something different.

As for git am being obscure - sure, seems a little, but then there are two things: 1. don't use it if you don't need it, and 2. for kernel development, this is remarkably useful!

3. Documentation: completely invalid. The man pages might seem a little terse, but then if you are looking up a command and you don't understand the terminology, then you should probably consider typing in

man gittutorial

Which, incidentally, can be found here: http://www.kernel.org/pub/software/scm/git/docs/gittutorial....

Alternatively, if you are trying to understand how to use git (and it might be worthwhile for the author to follow this advise) then try reading the git user's manual, which can be found here:

http://www.kernel.org/pub/software/scm/git/docs/user-manual....

Hint:

git rebase is explained here: http://www.kernel.org/pub/software/scm/git/docs/user-manual....

To understand how git checkout works, read here: http://www.kernel.org/pub/software/scm/git/docs/user-manual....

4. Information sprawl: actually, I consider myself to be a git newbie (mainly use github!) and frankly I've not needed to learn that much about git so far. However, whenever I've come up against something new, I've checked the documentation and after about 5-10 minutes I've understood the concept needed to get me going. I don't consider myself to be an expert in git in any way. However, as someone who has to program, I tend to find that for any system with enough power, I have to learn new things regularly. git is one of those things. Learn to love it :-)

5. Leaky abstraction: first, don't make the title "leaky abstraction" if you don't believe that there is any abstraction in the first place.

Secondly, it looks to me like they are trying to take your branch and insert it into another repository? Can't quite tell what is required here... certainly I'd love to see the way that this would be done in SVN!

6. Power for the maintainer, not the user...

??? I'm sorry, but the author is complaining that git is powerful, and works really well in highly distributed systems where you have a lot of parallel commits? Well, uh... duh?

The complaint here is that it's not usable for "ordinary" repository users. I would consider myself a fairly ordinary user, and I can honestly say that I don't consider that git is that hard to use.

7. Unsafe version control

DON'T DO THOSE THINGS!

8. In the traditional open source project, only one person had to deal with the complexities of branches and merges: the maintainer. Everyone else only had to update, commit, update, commit, update, commit…

Which meant a massive bottleneck when doing branching and merging. That's the whole point of git - it's version control done large. Or otherwise known as "distributed version control". I'd recommend the author read up on some of the advantages here: http://git-scm.com/about

9. I don't really have much of an opinion on this.

10. Github != git. For the record, I love github and I really don't find it that hard to use, or anything so complex that I can't do it fairly quickly.