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
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:
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.
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....
It says it does "Update remote refs along with associated objects". What is a remote ref? It's not mentioned in the man page nor in git tutorial.
So maybe I can deduce it from how it used? I see in the syntax that I specify a 'refspec'. What is a refspec? It is explained in terms of 'ref's. Hence, I still cannot make sense of ref, refspec or that man page. Things like these pop up all over the place.
I love git. But it took very long until I even understood some basic stuff. And according to the OP, I am not alone.
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...
I think a cardinal virtue of documentation is to but info where people expect to find it. Saying "Oh, you read the MANUAL. When I said RTFM, I mean the MANUAL for the TUTORIAL" isn't much of a help. If the documentation isn't where novices expect to find it, it doesn't exist.
Unsafe version control
DON'T DO THOSE THINGS!
How many can be done by accident? Are you using revision control at least in part for the ability to recover from a stupid accident? The fact that it isn't safe means you can't count on it being safe. You can't use it as essentially a way to have real point in time recovery for your repo, and it also means you can't count on it being an audit trail because at a minimum it could bet wiped out. That's fine, but it's worth stating up front that this is something Git doesn't do very well. Fine. Understand it is a tradeoff.
Doing those "unsafe" things in git by accident in a way that is unrecoverable pretty much requires you to be so drunk that you wake up the next day not remembering what you have done.
forcefully pushing things to remote repositories can be denied with hooks, so if you really do not trust the people with push access you can use that. For anything else, it's pretty much always possible to undo any damage by using the reflog.
In my experience, git is the least unsafe VCS I've used. if I commit a file, I know it's safe from accidental removals (as long as I don't touch .git). If I push the commit to a remote (private or public. Could even be on the same machine), it's safe from anything I do locally. So if I am going to do a complicated merge or a rebase, I first make a temporary commit to save the state of the repository and ensure that I can always undo any mistakes. You can't always do that in svn, since commits are immediately public.
Doing those "unsafe" things in git by accident in a way that is unrecoverable pretty much requires you to be so drunk that you wake up the next day not remembering what you have done.
Or more likely not knowing what you are doing, getting disoriented and combining the wrong options.
I haven't been using git for that long but I could totally see myself getting confused and typing something like that in by accident.
Even then, you can get back to something sane by using the reflog: master@{yesterday} refers to the master branch as it was 24 hours ago, and you can view the different things you've done to HEAD by just running `git reflog`. It's really really hard to blow away the reflog without meaning to -- you're much more likely to just `rm -r` the whole repository by mistake.
The documentation is, in fact, in a place where novices can find it. There's a man page with tutorial information.
What I find amusing is the paucity of information you find in man svn. Try it, you might be a little surprised! Though I have to admit, svn's inbuilt help is quite good.
With regards to not doing the things that can destroy data, in actual fact (as has been pointed out below) there is only really one thing that can't be backed out of is git gc, everything else can be recovered from the git reflog.
As for git having an "audit trail", it has never claimed this.
Please feel free to name a few :-) I've come up against a few of them, but nothing that I've not been able to work out with the documentation available.
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
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.