A really unfriendly and not so fair approach to GIT vs. Mercurial
Okay, this is one of the posts I wanted to since about 1 year, but now, nearly 2 years after the first git vs. Mercurial blog post I finally made it to actually write a second time about this topic. A first notice: I won’t cover bazaar. I personally hate it with passion and think it is the worst approach to DVCS ever. Nevertheless git and Mercurial fight in the same game with the same weapons (unlike bzr which is just far behind).
WARNING: This is the most subjective, most pointless approach to this topic ever. I didn’t read it myself a second time, I just published it.
I will start the same way as last time:
Git is a decentralized version control system written by Linus Torvalds to replace bitkeeper as the version control system of choice for the kernel because of licensing issues (okay I know this is the short story and it was much more complex and you can write a thousand lines about that, but it’s enough for most people). Git is designed to be fast. Everthing is optimized in that way. It contains a huge C written core with a lot of bash and perl scripts around it. A few years ago the C written part formed the so called plumbing. Nowadays the git community tries to replace high-level commands written in bash and perl that call the plumbing commands with c-written code to get a more consistent code base.
Let’s make a long story short:
Git is powerful. Awesome powerful. This is true since git’s beginning, but back then it lacks a good interface and the git community did a great job in improving the horrible interface git had once. Git is still awesomely fast. Commits, bisecting, everything works like a charm particularly on big projects like the kernel. They can rewrite history, they are doing a great job in helping intergrators to apply patches, reviewing them, and pushing to multiple sources. Everything about git is really unique, their focus on a powerful command set, their branching support and their targeted audience. I want to talk a little bit about that fancy branching support. Frankly, every version control system, even the 3rd generation decentralized ones have a pretty conservative way of doing branching by giving every changeset a name that the changeset belongs to (at least this is true for mercurial, and called named branches there). Git just gives a sh** about that and takes a version control branch the same way as a tree branch. It’s just an unnamed branch of the DAC. This gives you the awesome possibility to great huge set of local branches, to merge, rebase them without any bigger problem or even just discard them (actually that is one of the biggest problems in mercurials bookmarks implementation). Another just great feature in git is the staging area. You can stage hunks, as a virtual repository that is used to actually commit the ‘selected’ changesets. That’s awesome and I’m really missing that in most of the version control systems that I use. The idea of a staging area is just a huge win for git. It’s so incredible powerful. Okay to put it in a nutshell: git is just awesome, but….
There is Mercurial.
Okay some kind of a warning in advance: I contributed two well known extensions to Mercurial, I hang around in their chatroom and I think that I’m a well known part of the community. Nevertheless if you talk about Mercurial and compare it with git you have to take care. Mercurial is by far not as powerful as git, and…that is just the best think about Mercurial. Matt really keeps it simple and clear for everybody. it’s so incredible easy to understand in the first place. There are no weird commands with a thousand of flags. Okay I try to be fair. Mercurial is much less powerful than git in the first place. Because it tries to keep everything simple. There is no rebase, no cheap branching, no staging area. But there are extensions. You can learn Mercurial and know all it’s commands within 24h. They are really easy to learn, and not powerful, but they can be extended, by a large range of extensions. You can have cheap branching (bookmarks), you can have kind of a staging area (record extension), you can have patch management on top (mq) and much more. With all those extensions, Mercurial is as hard to learn as learning all git commands (which frankly is not necessary at all), but it’s more of a evolutionary approach. I know a thousand people who say that learning git is as easy. Okay, no problem. I don’t think so but it doesn’t matter, but frankly, git is missing 2 big points. Windows and an application integration: If you live in your nice Linux/BSD/foo world you are right. Git is awesome, but come on, I don’t have a freaky Windows machine, but I know that 80% of all people and more than 50% of all programmers use Windows. No they are not these bad, not geeky enough people. They are the real programmers. Those who are not freaks and take programming as a job. They don’t care (and thats good) about their environment, they just want to get things done and want to earn money. That good. And even that is not quite true for most of them, they do their stuff just faster on Windows than on Linux, therefore it’s better for them to use Windows. Okay, you might argue, but there is mysysgit and it’s even part of official git. Oh nice arguement, but frankly, junio doesn’t provide Windows binary, there is no official site to get them from, and ….. git daemon still doesn’t work perfectly nor does git-svn. It just sucks. Big -1 from me for that one.
The second pint is the worse git internal design. It’s soooo unix style. It’s cool for people that love Unix (like I do), who pipe around at least 3 commands, and know that I it starts to get funny if you pipe around 5 commands. But most of the developer want to use a nice integrated version control system. They don’t like to use fancy command line stuff with a thousand of flags, they want to do click&click (the german expression would be ‘klicky-bunti’). They want to have it integrated in their Eclipse, their NetBeans, Visual Studio, their Windows explorer and so on, and frankly, git does a poor job in that area. I know there is an eclipse plugin (but the mercurial one is stilll a thousand times better), and all this fancy stuff, but what do they do, damn, they have to parse the shell output. This means either git will never ever change their shell output (which would be sad, e.g. I hate the # in git status), or they will break older stuff. Mercurail on the other side is really easy to interface with. Okay you need python but that’s all. Everything else is just smooth. It’s easy to handle, it’s easy to integrate, it just works fine. Git really does a bad job on that. And the git community knows it. That’s why they start their libgit, and libgit2 project, because they know something like a git library is needed.
Okay it’s late and I want to finish that without reading it a second time, no frankly, this time I want to be completely unfair, without any objective argument: So here comes my final words, make them:
If you like to play with software, if you really like to have the power, go for git, if you use Linux, even better, go for it, there is nothing equal to the power and the fun you can have with Git. You can be a thousand times more productive. But if you, or people in your team are not tech-geeks. If you use Guis and want to use Windows, believe me, you better use Mercurial. I really love both systems (as long as you don’t use bzr even SVN is fine), but in this use case Mercurial is just better. Think about it.
shame on myself: song for this post: This is the life by Amy MacDonald