Mercurial developer responds to "Switch to git?"

After 4 years of Git and 1 year of Mercurial, I like them roughly equally. I love cheap local branches, I also love MQ. They're just tools, I wish people could get over this kind of stuff.

If this is really about getting more contributors, I suggest a GitHub mirror. We do that, it's not a big deal (hg-git is pretty good), and it does get us more contributors.

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good.

"I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. "

I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use, and actually i consider the things that git does differently to hg to be demonstrably and measurably counter-intuitive and in some cases dangerous.

the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state.

why can't i roll back a merge in one step if i didn't configure things to be able to do that? why does my branch disappear when i merge? how do the jenkins guys break their repo so casually and find themselves struggling to recover it?

i believe this is the robustness mentioned here: "The changeset graph is in some sense more "robust" in that it's just there and doesn't change on its own initiative"

mercurial seems loathe to alter history - which is pretty sane and common sensical seeming to me, git does it as part of how it is 'supposed to be used' which frankly sounds as mad as travelling back in time to shoot your grandfather. for these reasons - to me - using git is asking for trouble (it has caused me trouble and i switched to hg for precisely this reason).

i cant reasonably recommend git to anyone... which is a shame. other than that flaw it is really quite rich and powerful and has other advantages over mercurial - including (perhaps foremost) its enormous popularity.

EDIT: watch as this gets downvoted from hipster gut responses instead of thought :D

Agreed. Honestly, I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Do we need source-control on our source-control? Or at least simply flag squashed commits instead of destroying them?

This type of response is quite common in many open-source communities.

The trick to finding it is to consider carefully the motivations of why someone wants to participate in open-source. If you have a problem, you wrote a tool to solve it, and you want to share that tool with the rest of the world, you won't be threatened when someone else has a competing tool to share with the rest of the world. Just explain why your tool is useful, and under what circumstances, and let people make up their own minds. It's no skin off your back if they choose not to use it.

If you participate in open-source to gain social approval and hacker cred, however, then it's very threatening when other people choose to use a competing tool. If your users disappear, so will your social approval, and you'll be left feeling alone and unwanted. And so people who are in open-source for this motivation frequently put-down technologies that that compete with their own favorite tools. Sometimes it's not even the tools' authors that do this; it is people who have adopted the tool and feel like their choice of preferred tool will be threatened if others adopt different tools. Hence, fanboyism.

I have found, when evaluating technologies, that I rarely go wrong trying to select for the first category of community over the second. The problem is that there's a bit of an adverse selection effect. If you ask "What's the best framework for X?", then all the people in the second category will rush to defend their favorite tool, while the people in the first category may present cogent arguments for their tool of choice but won't seem all that impassioned. Human beings are hard-wired to recognize passion, but we typically cannot recognize experience until we have had that experience itself. And so your natural tendency will be to pick frameworks in the second category unless you specifically try to look past the arguments and look at the motivations and background of the people making the arguments.

I use SourceTree for git, but I find TortoiseHg is better for mercurial; it's just far more feature complete, with support for almost all mercurial commands and (bundled) extensions.

I'm still somewhat surprised by how poor git gui's are, considering it's the more popular VCS - though SourceTree is certainly one of the better ones.