Mercurial developer responds to "Switch to git?"

All systems have different tradeoffs depending the target audience that they are trying to optimize for. When comparing bzr, hg, and git, one way of thinking about it is that they differ in the size of the developer community of the project that they are trying to optimize for. The sweet spot of bzr is probably up to ten or so active developers at one time; for hg, it's probably up to around hundred or so; and for git, it's designed to scale up to several thousand active developers. Different people might want to argue over the exact breakpoints, but in terms of orders of magnitude, I think it's pretty close.

One comment that was made in a thread below was that git was optimized for the people who integrate code, as opposed for those who actually produce the code --- and I think that's mostly true. Which is to say, when there was a choice between optimizing for a project which might make things easier for the integrator, or for the sub-integrator, or sub-sub-integrators (in Linux code integration happens in hierarchically; it's the only way we can scale), and making it easier for a newbie coder, git has very unapologetically optimized for the former. It's true that there are some warts which caused by legacy UI decisions which would probably have made differently if the designers could go back in time, but in my mind these are in the cateogry of things like TAB characters being significant in Makefiles; it's annoying, but practitioners very quickly learn how to deal with these warts, and they generally don't cause significant problems once people get over the startup hump.

The other observation is that since choice of which DCVS gets made is generally made by project leads, who tend to be the integrators, it's not that surprising that git is very popular for them. It's also true that most project leads tend to be over-optimistic about whether their project will be the one that will grow up to have thousands of active committers (just as most startup founders are convinced that their baby will be the defeat the odds and become the wildly successful IPO whose market cap will exceed $4 billion dollars :-).

Given that most projects generally don't have thousands and thousands of active developers, it might be that hg is a better choice for most projects. However, if most of your senior developers are more used to using git, because that's what they are mostly familiar with, maybe you might want to use git even though the project's scale is one that would be quite satisfied with hg. For me, the e2fsprogs project falls in that category; while the number active developers are such that hg would be fine, most of the developers are simply much more used to git, and so we use git.

The third reason why git has probably become popular is because github is really good at hiding many of git's rough edges, and if people are used to github, then it might be a good set of training wheels before people graduate to using git without github's training wheels.

If these three factors don't apply to your community, then maybe hg is a better choice for you. If that's true, then don't hesitate! One thing that most people forget is that while transitioning between DCVS is painful, it can be done. So if it turns out the situation changes in three or five years, it is certainly possible to convert your project from hg to git. It will be rough for a month or two, but for some projects, that might actually be better than starting with git, and then finding out that it caused some increased friction initially, and that they never needed the scale that git provides.

Tools are important to the craftsman. Plus, some people care about the entire process of building and not just the final product.

This of them as major modes for Emacs, if you're familiar with that. Emacs comes with syntax highlighting support for a lot of languages and the mode is turned on automatically. Sometimes you need to install a new major mode yourself, but the bundled modes get you a long way.