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.
I think the major advantages of git are that merges work, and that it's easier to create atomic patches with commit --interactive. It's also easier to create clean patches by combining that with rebase. Clean patches don't matter much if what you're doing is committing to a repository. But they matter a lot if what you're doing is sending in a patch to be reviewed. For a project that has a core team of coequal committers, svn is OK. For a project where everyone sends patches, git has some advantages.
This, too, seems solving a problem I don't have.
svn diffs make sense to me. They survive email well. They are easy to create. I have never had a problem applying patches sent to me in email.
Likewise, I've never had a problem with merges in svn. They just work.
So when people tell me these two things are so much easier in git, I wonder, easier than flawless? How does that work?
"But they also encourage people to work at great lengths in a vacuum" I actually have the feeling this is even worse with svn. People do not commit because they don't think it's ready yet. (Or don't have commit rights) So it stays on their local disk without even being committed - or even versioned.
"Having a situation where people can hack on the code without participating in the community seems to be clearly a bad idea." To me it's a better way than maintaing patches manually.
Local branches for topic branches are a God-sent. Having the whole repo at your finger-tips - great! I admit I am also not so happy about terminologies and commands syntax, but the "commit -a" story is really simple. And if you want a push on every commit, hell, define an alias in the gitconfig.
Really not religious on the tools. Everyone should use what he wants. But unfortunately your post sounds a bit like "Why would anyone want need a color TV? I am used to B&W and it's fine!" You sure you really gave it a fair chance?
Hmm? Really? The thing is, having used git for a couple weeks, I really can't tell that it give me *anything* I didn't already have, and it makes the things I already had so much harder. Perhaps I'll get more out of it over time.