Git vs. Mercurial

---

---

With the dawn of DVCS many different systems emerged and their number is increasing. Since the beginning, two major solutions fight for the throne of the “best” DVCS: Mercurial and Git. While both do their job very well there is an almost religious debate which one is THE best.

This article tries to give an objective view on both version control systems and hence helps to decide which one is the best for your project to come.

Git

Git was developed by Linus Torvalds to replace BitKeeper, a proprietary SCM-System used for the linux kernel development. After the free use of the product was called off and no free system on the market met his needs, Torvalds began his own development. His intention was to create a system as powerful as BitKeeper.

Git was designed to be flexible, robust and above all: fast. Originally designed to be a basic version control system Git grew quickly and became a full fledged revision control system with a unique design approach. The most important properties of Git are:

• Efficiency in large projects: Git scales very well with projects of growing complexity and is faster than most other systems.
• fast merging and branching: Both operations perform very fast and the lightweight branch concept emphasizes the non-linear development idea behind Git. A fairly unique option in Git is the “octopus merge”. It allows to merge more than two revisions of one file in one single step while maintaining integrity.
• Distributed: Every developer holds a local copy of the development history and changes are copied as branches between the histories. There is no difference between local and remote branches during a merge.
• Toolkit-structure: Git is basically a set of separate programs written in C and a set of scrips to wrap their functions. Those plugable parts are easy to switch or expand.
• Object packing: Git stores all new files separately and compresses older files into “packfiles” for efficient storage. To maintain the efficient structure, Git also does a periodic repacking which can be a very resource-consuming operation. Therefore it is best scheduled at the end of a workday.
• Garbage collector: If the user leaves loose ends in the history, for example by backing out changes, an automated garbage collector will clean up the repository to prevent pollution of the history.

Git is highly flexible and if you want to realize your own revision workflow Git could be your choice. It allows you to review the history of an older revision and change the commit history itself. But where is light there is shadow, Git is by no means flawless:

• Git reveals lots of it’s inner options to the user, which could be overwhelming or deterrent.
• Documentation! There is almost none. If you learn Git from scratch prepare for long searches in Google and co. To get going it is in general more advisable to learn Git from experienced colleagues than dig around the web all by yourself.

Mercurial

Although Git and Mercurial originated from the free version of BitKeeper in 2005 as a replacement in linux kernel development, Mercurial puts a strong emphasis on simple usage. However both pursue similar goals: high performance, scalability, decentralized structure and robust version control. Even though Git became the successor of BitKeeper for Linux, Mercurial developed into one of the most common DVCS’s.

While Git uses the tool-kit approach to stay flexible and adaptable, Mercurial is one single monolithic binary that for simplicity sake omits certain options, e.g. editing previous commits. In the view of merging, committing and tagging both systems work equally, but Mercurial is slightly slower. Since Mercurial encapsulates it’s functionality very good, it is fairly easy to learn the basic options in less than one day.

So, who wins?

First of all it is not easy to compare Git and Mercurial, because both share the same underlying idea of distributed code management. Git is fully configurable and can be adapted for different workflows. It is a long and hard way to master this system. Mercurial is easy to learn, but it lacks in flexibility compared to Git. To sum up, there is not the perfect choice for all situations.

For larger projects with many contributors and high dynamics Git is most likely worth the effort. If you are looking for a fast and lean way to start distributed version control, Mercurial might be the better choice. With some experience in Subversion, Mercurial shouldn’t be a problem.

All in all, a Git-user will most likely not sacrifice the liberty of designing a personal workflow for the sake of simplicity in Mercurial. And vice versa a user of Mercurial might value simplicity more than the variety of configurations in Git. When comparing Mercurial to Git, Mercurial is often said to be easier to use but less configurable. At a first glance this might be true. But using the advanced configuration methods of the command line, you can configure Mercurial in the same depth as Git. You just need to know how to do it.

Generally, we recommend to select the best system for each project based on the project requirements more than personal preferences. There are many clients available for both Mercurial and Git to fit everybodies’ preferences.

Git and Mercurial in SCM-Manager

Using SCM-Manager enables you to manage Git and Mercurial projects in one interface with no additional effort. Therefore you are free to choose the best fitting system for every situation.

Finally one advice: Evaluate your work and choose the best tools to do it, keep flexible and open for new possibilities and stop arguing about the tools and get to write some code!

---

---