The author is, of course wrong about git vs svn safety. Once you really know git, it is more forgiving than anything else. Almost all mistakes are recoverable. Not so for svn.
The author is right about git having a usability problem. Git is hard to learn. I'm sure some of us had the same initial reaction. Personally, I'd love to see someone put a gui skin on git that uses different terminology, picks the most newbie friendly defaults, and makes the workflows easier. P4v, for example, is easier to use than Sourcetree or Tower or other GUIs that basically only give you menu options for the things git does. Not saying that p4v is the awesomest, but I've watched artists manage with p4v, and artists largely don't in git.
It took me a while to come around, but now I'm so sure that git won't lose anything I am much more willing to try things I don't quite understand than I ever was with any other version control. Yes, sometimes recovering can involve some opaque incantations, but I know whatever I wanted is still there.
Just because something failed for you, doesn't mean it failed for everyone. One of the author's main points is talking about GIT GUI's, which I think is his/her primary problem. Terminal based programs, nmap, git, gcc, emacs, vim, etc. Don't lend themselves to GUI-ization easily. To attempt to categorize their vast functionality in terms of drop down, or pop up menus and buttons is largely an exercise in futility.
Personally, I'm more excited to see a blog post from the author working on a headless server for the first time. I think he could give a wonderful review of the Bourne Again Shell.
"Fatal error: Out of memory (allocated 3670016) (tried to allocate 7680 bytes) in /home/auroand/public_html/thefuriousgeek.com/wp-includes/l10n.php on line 530"
Git is complex because version control is inherently a complex problem. Let's look at some of the Git complexity that people don't like, and why they should:
Branches: Especially if you work on a team, but even if you work alone, you definitely want branches. Often you'll want to work on an experimental or not-production-ready feature or refactoring. Yet you'll still need to be able to jump to the production codebase and maintain it, e.g. when a high-priority bug is found. Branches assist you in this and other scenarios.
Local commits: You shouldn't need to rely on the network just to save your progress.
Cloning: Every developer's Git repo is a complete copy of the main repo. That gives you an automatic backup system for every project. If you've ever seen corruption in a central SVN repo, you know how important backups are. Yes, with SVN you could implement your own backups for the central repo, but with Git, it's one fewer thing I have to do.
Adding a.k.a. staging: If you've changed a bunch of files but only want to commit a subset of the changes, it's nice to be able to add them incrementally. The alternative is to have to type out all the paths in one big commit command, which isn't as user-friendly.
I hated git and felt much like the author did when I first started using it. Git has some problems. Of course some of the problems stem from its features. To me its biggest feature is "branching" and I'm guessing this is why many people like it. It makes it trivial to work on multiple bugs fixes at one time, without mixing code.
Checking in locally can be nice, but I agree, why do I have to do that when I'm networked?
But the power of the simple branches pretty much outweighs all the negatives.
And of course it would be nice to have some good GUIs
For anyone who would like to work with Github but prefers svn. I can't personally speak to how well this works but it is available.
(OT: I first found out about svn support from a presentation by Zach Holman, I believe you can find it here: http://zachholman.com/talk/git-github-secrets/ Some interesting bits in there. )
Tower is, in my opinion, the best and most full-featured Git GUI. Having used it within multiple teams, I've found that it helps users understand what's happening under the hood (esp. regarding remotes). Unfortunately, the author seems to be a Windows user and Tower is, as of today, only available for OS X.
While I don't agree with the post I do think anyone that can meld the power of git with the simplicity of dropbox will have a killer service. But I'm assuming thats like having your cake and eating it to.
Are there any notable projects that try to accomplish this?
Is this satire? or a real rant!? I get that git has a bit of a learning curve to learn "all" of the techniques, but it's really not that hard to get the basics going.
I'm assuming this is a real rant, as he touches on a lot of the problems with Git. Git does have a steeper learning curve than other source control systems. And many of its features are not exactly intuitive.
But, two things:
The author is, of course wrong about git vs svn safety. Once you really know git, it is more forgiving than anything else. Almost all mistakes are recoverable. Not so for svn.
The author is right about git having a usability problem. Git is hard to learn. I'm sure some of us had the same initial reaction. Personally, I'd love to see someone put a gui skin on git that uses different terminology, picks the most newbie friendly defaults, and makes the workflows easier. P4v, for example, is easier to use than Sourcetree or Tower or other GUIs that basically only give you menu options for the things git does. Not saying that p4v is the awesomest, but I've watched artists manage with p4v, and artists largely don't in git.