Tag Archives: git

Git and SVN

I’ve been hearing about Git for several years now. As far as I could tell from the hype, it solved a number of problems that I didn’t have, and introduced a very odd view of community.

I find the religious fervor surrounding Git and Bzr to be very unconvincing. In fact, the more rabid the supporters are, the more they push me away from using it, because the arguments surround this passion, rather than being based in solid technical reasons. “It’s better because it’s better, and because svn is stupid” seems to be the summary of most of what I hear.

So I decided, finally, to actually give it a try so that I could have an opinion based on fact rather than on hype.

Offline commits are clearly a cool thing, for the very rare occasion when I am working on code and don’t have a network connection. But they also encourage people to work at great lengths in a vacuum, without community feedback, and then commit a great wodge of code all at once, resulting in unreviewed commits. This is clearly (to me, anyways) a Bad Thing.

Indeed, most of the features that are hyped as The Reason To Use Git fall into two categories for me. 1) Things that solve a problem I don’t have. 2) Things that seem clearly a bad idea.

1) Cheap branches. Subversion has cheap branches. When pushed, the Git folks say, yeah, you’re right, but CVS doesn’t. … CVS. Well, ok.

2) Fork and hack without all that overhead of connecting with the community. This seems short sighted. Or perhaps it was just very poorly stated. Having a situation where people can hack on the code without participating in the community seems to be clearly a bad idea. Open Source without community is not something that appeals to me, at all.

3) No central repository. Well, in addition to not being true (every project that I’ve heard of does in fact have one master repository that everyone syncs to) this seems to be a bad thing. It seems to promote disunity. And it solves a problem that I don’t feel I have. Major architecture changes can happen in branches in svn. Minor features can happen in branches. Fiddling about can happen in branches. All of these should be working towards a product. If a major change becomes the community-accepted product, then folks switch to that branch as the new trunk. This is all possible, and done every day, with svn. But the everybody-is-trunk thing that gets talked about doesn’t seem to actually happen in the real world.

4) Offline commits. Yes. This is a cool idea, and I look forward to having this feature in the next version of svn. However, it’s not something that compels me to switch to git.

5) Every command does one tiny thing, by design. This makes me CRAZY. Committing a change to the repository – the one up on the network, not my local working copy – takes three commands: git add, git commit, git push. Yes, I’m aware that I’m using the terms differently than Git does. That bugs me, too. Redefining vocabulary as a means to set yourself apart from the herd is just infuriating. Yes, I’m aware that the first two commands can be combined (git commit -a) but I’ve also received very contradictory advice as to whether I should do this, ranging from “Always do this, it’s the only way” to “Never, ever do this. It’s dangerous.”

For the record, yes, I have used Git. In fact, I started a new project using Git, mostly because I want/need to learn about Git, but also because I was starting to get sold on the hype. So I’m not operating entirely in ignorance. I expect I’ll get more familiar with it, but so far it’s been an unpleasant experience.