Update: (later that day…) A full stomach changes everything. Getting some breakfast lessened my git hatred quite a bit. Still, it manages to irk me on a daily basis, and I hate people who make their ill-thought-out blog posts disappear, so I will leave my hate-filled rant for posterity and a warning to myself not to post before I eat breakfast.
Update 2: (Feb 2010) I’ve been meaning to update this for a long time. I’m a 100% convert to git now. I’ve had my religious epiphany. I couldn’t understand how great it was at first, but over the past year I’ve finally wrapped my head around it. So, to all you haterz out there like me, just keep persevering. The light is there at the end of the tunnel. Now, back to the original rant…
Ok, I’m angry, so I’ll go ahead and make a ranty, heretical statement:
But wait! Micah, aren’t you the ultimate Rails fanboy? Don’t you jump on the bandwagon for everything the rest of the Rails lemmings do? RESTful routing? .html.erb instead of .rhtml?
Yes, in general, I do follow all the other Rails conventions and try to stay on the bleeding edge. I hate to feel like I’m falling behind, and that’s an easy feeling to get in the Rails community. So, I try to follow all the trends and at least educate myself on what it means and how it works. In most cases, like being RESTful, I eventually come to understand the underlying concept and appreciate the change. Learning new things often involves suppressing your own skepticism and the urge to stick to the known path.
So how is git different? Well, I’ve been using it for a few months, and the list of cons just keeps growing, while the list of pros stays nice and small. Sure, it’s fast, merging is dead simple, and I can scoff at all my friends still using subversion. But, every single time I want to do something, I have to look up a whole slew of commands. Why can’t I just memorize them? Because they’re horribly arcane and obtuse.
Want an example? Try deleting a remote branch. This seems like something one would do often, after merging a feature branch into the master. However, rather than using something simple, like “delete the remote branch”, you have to cast some arcane spell. For me, deleting a remote branch involves Google, every goddamn time.
The spark that set me off today was my attempt to connect to multiple repos on Unfuddle. For organizational reasons, I need to have multiple user accounts. Juggling usernames and passwords is bad enough. Luckily, they’ll allow me to use the same OpenID for both accounts. Still, when I tried to add my public ssh key, it complained that you cannot use the same public key for two accounts. Apparently, Github has the same policy.
Well, that was two hours ago, and I’m still trying to figure out how to get git to use my shiny new ssh key that is not named id_rsa. A little stumbling around got me some instructions on Github, but right at the top it says that it’s not an ideal solution and should only be attempted by advanced users. Hmm, using multiple different keypairs for different source control repositories does not exactly sound like an advanced feature. Do they recommend we use the same password for all our websites as well? Seems like a pretty basic concept to me.
Update: I was called “borderline retarded” in the comments for blaming git for the policies of github and unfuddle. Harsh, but true. I conflated git with hosts who provide git, and that’s not fair. So, github and unfuddle, my anger shifts to you!
Further, the recommended solution requires editing configuration files for ssh. So, I have to be an experienced ssh user to use git effectively? That’s ridiculous. Seriously, how many developers ever modify their ssh settings? I’ll muck around in git config files without worrying too much. Change settings in ssh without extensive research? Forget about it. Mess that up and you’ll lock yourself out of your machine, or worse, open it up wide to script kiddies who know more about ssh than you.
From a usability perspective, git sucks, and that’s that. If anyone feels compelled to defend git, please do so in the comments. However, don’t tell me how to do the things I’ve bitched about here. Tell me why it has to be so goddamn hard. To make an analogy, it reminds me of the Rails vs Java mentality. Java web apps are horribly convoluted. Sure, you can write tons of arcane XML and eventually maybe get your WAR deployed into Tomcat correctly. But why? Why waste time on this crap when it can be so much easier? Why spend minutes and hours trying to understand the obscurities of git when subversion, the ugly stepchild that it is, is still easier to use?
Subversion has its problems, but dear God why did the Rails fanboys have to jump to a worse solution? Now, in order to keep my certified fanboy card, I need to spend my precious development time tinkering with git, and then writing blog posts about how much I hate it.
November 23rd, 2008 at 10:35 am
To be honest, I think it’s just a matter of getting used to it. I’m not as used to svn as you are, so for me, creating or deleting branches in svn also involves a quick google. The same is true for git, and much of the ruby api, because I’ve opted not to carry that information in my head. Over time, I learn the few git commands that I do use frequently. And if I use them *really* frequently, I write an alias for them. But if I don’t use them that often, the occasional googling is really not such a big deal.
So, taking git and svn as equally arcane (“svn up” isn’t any less magical than “git pull”..), I’d rather have the spellbook that allows me to cast giant whirlpool fireballs of death rather than the one which only teaches “magic missile” (sorry for the geeky analogy
).
November 23rd, 2008 at 10:39 am
@Daniel,
Hey, no problems with geeky analogies here. We (aisleten) are the guys who run http://www.obsidianportal.com so we know all about fireball vs magic missile.
I guess all my rants about git are colored by my (decent) knowledge about svn. I’ve never considered myself an expert, but I can get by without too much trouble.
November 23rd, 2008 at 10:55 am
http://cheat.errtheblog.com/s/git/
November 23rd, 2008 at 11:08 am
Same here – I am not saying git is not better, and I even think pros are definitely outweighing the cons _once you get used to git_ – but probably not before that. The learning curve is steep, and git has and endless bag of error messages to surprise you all the time… for a beginner, I think git is just too much in the way all the time.
November 23rd, 2008 at 11:14 am
I had basically the same reaction to Git. I’ve tried several times to learn it, and I just don’t get it.
So I went with Mercurial for my personal projects, after hearing that it was a DVCS that was actually easy to use. And so far, that’s true: it offers all the cool features that Githeads brag about, and is practically as easy as SVN to use.
I’d like to add a query for Git users: is there any feature that Git makes possible which is impossible in Hg? or that Git makes easier than the corresponding Hg feature?
November 23rd, 2008 at 11:26 am
Deleting remote branches isn’t really in the fast path of git use cases (i.e., you might be doing it wrong), but it’s still not that hard. If you really can’t remember the 2 mnemonically-flavored tags needed, then write the 2 line wrapper script and be done with it.
Your gripe about ssh has nothing to do with git. I don’t know exactly why Unfuddle and GitHub have the “no duplicate public keys” policy (maybe as a small hurdle for dickheads trying to circumvent the free account limits?), but blaming git for the policies of your repository hosts is borderline retarded.
November 23rd, 2008 at 11:27 am
We tried git and switched to SVN.
Several reasons: 1) no HTTP auth, just SSL. This is a pain to get new users going. Don’t forget doc writers and designers use source control too! 2) lack of windows support. Git on windows is a joke right now.
November 23rd, 2008 at 11:33 am
Try Bazaar. Launchpad.net certainly isn’t GitHub but man bzr is a shit load easier to use than Git.
They also have a helpful comparison page between them and Git (amongst others) http://bazaar-vcs.org/BzrVsGit
November 23rd, 2008 at 11:33 am
So git should provide tools for managing SSH keys? That’s the exact opposite of the Unix philosophy.
Should you be an SSH expert? Yes, if you’re going to relying on SSH for a critical part of your work flow you should know a thing or two about it. Have you tried using ssh-agent so that SSH can automatically pick the right key? I assume you’re encrypting your private key. If not, shame on you; ssh-agent can help with that too.
November 23rd, 2008 at 1:17 pm
This is akin to the “linux is harder to use than windows” idea. git is only harder to use than svn if the only sorts of things you need to do are the sorts of things svn is capable of. Maybe I’m missing something, but from what I see, svn doesn’t have stash, or rebase, or diff-chunk-by-diff-chunk commits, or interfaces to other RCSs, or off-line usability, all of which are things I use. So yeah, git is harder to use, and I do spend 40 minutes a day in the manual pages, but with svn that 40 minutes would be doing all kinds of patch, cp -r and diff to make more copies of the files I’m using that are supposed to be under revision control…
November 23rd, 2008 at 3:03 pm
Agreed that the git interface sucks (especially re:remote branches, as you point out). The mercurial interface is certainly better, and I would use hg over git if the community support for git wasn’t so superior.
(Another area where git sucks is getting a private git host set up so that your team can push/pull to it, more ssh hasslse. Gitosis helps a lot)
Anyway, where we disagree is in your conclusion. Despite the sometimes crappy UI, I think git’s painless branching, far superior merging, community support, excellent seb resources like github, and local caching of commits more than make up for svn’s crappiness.
November 23rd, 2008 at 3:28 pm
I don’t know how Unfuddle works, but the difficulty of managing multiple ssh keys is exactly why we recommend on GitHub that you only create one key and add yourself as a collaborator to projects you don’t own instead of trying to manage multiple accounts.
If you have any specific GitHub questions, feel free to email us: support@github.com
November 23rd, 2008 at 3:33 pm
I’m with Hg above, I like Mercurial. I’ve been using it for a bit and so far it has a lot of neat things that make me forget why dragged my feet when switching to distributed source control. I think the biggest plus at the moment for a svn user could be that you can use hg to pull from a svn repo, make local commits, then push back to the svn repo. It may not be beneficial for everyone, but if you have flaky hosting, or intermittent internet access that’s clutch.
It also has a nice interface for windows/osx users, which is how I sold it to my group. (I’m the sole linux user, but I am also the server manager heh)
November 23rd, 2008 at 3:59 pm
Occasionally reading that the lack of windows support is what turned people away from git is also kinda troubling, because it’s had solid windows support with mSysGit for a while now.
Check out this screencast: http://gitcasts.com/posts/git-on-windows
November 23rd, 2008 at 4:06 pm
For help remembering commands try Cheat: http://cheat.errtheblog.com/
For Git and GitHub help, including help for all the problems mentioned in this blog post (e.g. http://github.com/guides/remove-a-remote-branch), try the GitHub Guides. They are linked from your GitHub userbadge when you’re logged in: http://skitch.com/defunkt/hxmw
Git can be very hard to learn, sorry you’re having problems.
November 23rd, 2008 at 6:36 pm
Micah, are you serious? You’d rather use subversion than git + github?
Dude what are you smoking. You were probably the same cat wishes Ruby were more like PHP, right? Or that github were more like Sourceforge…
echo “get a cloo”;
November 23rd, 2008 at 7:07 pm
I think you would all be surprised at how unintuitive (svn/bzr/hg) is when you are not used to it. As a little experiment, I just tried to use hg to do some common stuff I do in Git and the git-haters/hg-lovers out there would probably be surprised at just how similar the two clis are now. Just type ‘git’ and then ‘hg’ on your command line to see how very close they are in what you actually have to type. And there are some unintuitive things in hg – you have to add ‘-m’ to the ‘hg resolve’ after a merge conflict for the files you fixed or it will reset all the work you did to resolve them, you have to run ‘pull/merge/commit’ for the equivalent of what ‘git pull’ does, you can’t switch back and forth between branches without providing ‘–force’, and if you do, you have to force the push too, you have to manually edit rc files to add more than one remote repo (git remote add) or add your username (git config), etc. It’s not the easy-peasy scm you think it is just because you’re used to it.
I’m not a hg user, and it’s certainly not difficult to use, but it’s so close to git that I only had to look online for a few things. I’m guessing most hg people should have about the same experience – the only huge difference was the concept of a staging area, which most git users love and is entirely absent from hg, but can be emulated with a ‘-a’ to the ‘git commit’ command.
I actually would probably be pretty OK with having to use hg for a client at this point, they’re so similar (though in my personal opinion, hg seems like ‘git lite’ in what it cant do), but I would hit my head against a wall if ever forced to use SVN, and would spend tons of time looking up stuff to remember how to do it (branching, merging, etc).
January 2nd, 2009 at 6:38 am
[...] back through some old posts, I see that I’ve become prematurely curmudgeonly. I also tend to judge too quickly, and am then forced to recant and eat crow. Since I’m not a [...]
January 18th, 2009 at 2:02 am
Honestly I have to agree with you but not for any of these reasons, I mostly just stick with SVN because that’s what everybody uses… There are countless IDEs that have SVN integrated, countless cross platform SVN clients. And to be honest, as a fairly small scale web developer, who cares about what features your version control software has? SVN works and does what it needs to, it’s highly stable and has a mature community surrounding it. I have no doubt that git is superior software, but at this point it just isn’t that mature.
February 6th, 2009 at 12:04 pm
I stumbled across this while in frustration, I googled for “Why I hate git”. I’m a relatively able coder. I use a wide variety of languages and run a continuous campaign to get my colleagues using some form of revision control system. This requires that said RCS can be dropped neatly into their normal workflow. SVN manages this. It may not be L33T, but RapidSVN provides a perfectly adequate GUI.
Now it’s cool that git has fancy features. I’m sure it makes life a lot easier for many folks, but I’ve just spent the last hour and a half trying to checkout (in the svn sense) a copy of a driver for x.org so that I can test a new feature that was recently added. Why? Well, because “checkout” has a completely different function to other RCSs. Because searching for documentation provides countless examples of how to carry out complex tasks, but not how to simple download some source code. Because once I’d manage to figure out that I had to clone the repository, and hacking around with branches finally had me using the correct branch, the code that I could see didn’t include the changes in the branch that I’d specified.
So off I go again, from the top, downloading another 28M of data (around 4M of which appears to be source code) in order to compile it.
This is not useable… it’s not even close to useable… it’s possibly the largest disaster in terms of usability that I’ve ever seen (And I’ve coded in VBA!).
So while the reasons for hating git that you gave above might have been mis-targeted, don’t think that you should cease hating git… there are plenty of other reasons left.
March 14th, 2009 at 11:04 pm
I will just chime in and as other, suggest you try hg / mercurial. It is designed to be used by human beings, whie having the power and performance of git. Git is designed to be a toolkit to build systems on. My advice to people is that it is OK to use Git if you have a Git guru in your team (or plan to become one). If you just want to use a SCM, just go mercurial.
June 10th, 2009 at 6:18 am
[...] zero comments, but I know they’re read by my close friends. However, I’ve had several blog posts that have generated a great deal of commentary. I provided some thoughtful analysis, and [...]
August 22nd, 2009 at 6:29 am
As noted by Dawkings, the majority of the world is clearly a victim of the God delusion. The rest seems to be victims of the Linus delusion.
GIT is optimized according to Linus’ way of thinking about managing the patch flow in the Linux kernel project. For almost all other projects (those not managed by Linus), GIT is just wrong.
For the rest of us, there’s a much better option.
That option is Mercurial.