I find it a bit surprising (if not hard to believe) that hg is more common than git in professional use. That said, I don't find it hard to believe that hg users have more love for their tool than git users.. Before becoming an avid git user I tried both and found hg's commands much more lucid.
Git support on Windows was really poor for some time (I gather it has improved though), whereas Mercurial pretty much always treated Windows as a first-class citizen. That may have something to do with it.
On the other hand, I do find it hard to believe that hg users love their tools more. Generally my impression has been that git attracts a lot of people who are, shall we say, passionate about their particular version control system.
Ahh.. The windows bit makes perfect sense. I wasn't aware (not a Windows user). Excellent point about git's community also. As obtuse as the commands can be (Really? git push :branch_name DELETES a remote branch?), I still love it. Also, the relatively high number of people who claim to love cvs in the survey suggests the bar for satisfaction might not be very high here :|
Because the momentum behind git is huge. Like I said, I preferred hg at first glance and still ended up a git user because most of the people I wanted to work with were on-board and github is awesome.
The momentum behind git is huge in a small community that thinks it is much more important than it really is.
Git's UI has always been very poor. Moreover, on Windows, merely installing a basic Git client requires jumping through silly hoops: if I wanted to run Linux on those PCs, I would be running Linux, after all.
For most developers, even those who are quite happy using CLIs in general and running on UNIXy platforms, having a UI that sucks is a serious disadvantage. Outside of those people working on major OSS projects like Linux where Git is the standard and those who like to use GitHub, Git has few compelling advantages over the other serious DVCSes to make up for their much better usability.
Also, just as an aside, Git is the only DVCS that has ever screwed up a project I was controlling with it due to a data loss bug. That puts it in a class with... well, only SourceSafe, really... in terms of how much I trust it to keep my code safe.
The momentum behind git is huge in a small community that thinks it is much more important than it really is.
Hmmmm. Momentum is a moving target. I'd be blown away if there was another source control tool in history who's userbase has grown as quickly as gits has in the last few years. As for important, I don't really think any of my tools are 'important'. They just let me get important shit done.
Also, I don't even know what "Git's UI" is, but I'm sure you're right about it sucking. I do take for granted my level of comfort using CLI for source control.
I'd be curious about the details of your data loss bug. Most git data loss is user error (though I'll admit the ridiculously obtuse commands and concepts make these very easy to accomplish when learning the tool)
> Also, I don't even know what "Git's UI" is, but I'm sure you're right about it sucking.
FWIW, I meant the CLI. I have rarely seen an interface that manages to make a relatively simple idea seem so complicated.
> I'd be curious about the details of your data loss bug.
It must have been a couple of years ago, so I can't remember the exact details and I imagine it's been fixed by now anyway. Basically, there was a problem (duly documented in their bug tracker; it wasn't user error) where Git would refuse to update one copy of a repository from another properly. If memory serves, it was related to switching between branches in some way.
It's possible that I was being unfair in calling it a data loss bug in Git, because I have a vague memory that they determined the remote repository itself wasn't corrupted if you knew how to rescue it. However, the effect was that the local working copy on my development machine didn't have the data in it that it should have, and ultimately I don't really care why my data isn't there, only that it isn't.
