Why is Git better than Mercurial?

DZone 's Guide to

Why is Git better than Mercurial?

· DevOps Zone ·
Free Resource


Which of the two main distributed version control systems (DVCS), Mecurial and GIT, is better and why? This is an old argument, with forum posts galore about which is better; with users of both arguing their case, however this argument never seems to be resolved. This is because the feature sets are so similar, and after researching the various strengths and weaknesses it became clear that they both have clear advantages for certain situations, – different use cases. Below we have listed both pros and cons for both Git and Mercurial in order for our readers to be able to make their own decision as to what is best for them, after all user requirements and team requirements differ; there is no one size fits all.

Commonly found comments about Git

GIT is overly complex in every sense of the word, in particular the information model and the command line syntax as well as the help documentation, none of it is easy to understand. The statement “if you don’t understand the functionality don’t use it, just use it like subversion” just doesn’t fit for the simple reason that most commands lead to further commands, where simple actions can require complex actions to undo or refine.

The decision as to whether to use Git on a development project or not, is primarily a question of how knowledgeable of Git the individuals are within the team, a single weak link can bring down the entire team. The obvious example of this is seen in the version control of Git. It is simply put, – unsafe, – prone to accidental alteration by users (potentially affecting the entire team), therefore a high minimum knowledge requirement is necessary. Consider a Git test, what should the pass rate be? 70%, 80% or 90%?

Continuing on the overly complex nature of Git’s design, the obvious point is that it puts control firmly in the project managers hands or whoever is maintaining the codebase, you might wonder why that is bad? The problem is that the majority of Git users are coders (contributors) and what they need most of all is a clean interface which is where Git fails to deliver, putting functionality over usability, favoring the maintainer over the contributor.

Pors and Cons of Git and Mercurial

Git is different but not necessarily better than Mercurial

It is often said that working with Git is much better then Mercurial. The two clearly have pros and cons but one is not necessarily better than the other is. It is all depends on your knowledge and expectations.

  • The method by which both Git and Mercurial handle history, is essentially just a directed acyclic graph. However, Mercurial provides you with a simple linear history that can cause confusion due to the lack of information, whereas Git enables you to follow the history backwards but this is complicated and hard to follow, therefore this can cause confusion.
  • It is often an argument that Git handles branches better than Mercurial without any particular reason. As a Mercurial user, you might see two branches (named branches and repository clones) and all your changes will belong to a named branch. The confusion starts if you have many with the same name. Branches structure in Git enables you to avoid putting code where you did not want.
  • Git enforces technical excellence; – if you do not know everything about Git then you should not be using Git else you are a danger to others work. Simply put, a Git team is an expert team.
  • Git is more powerful for larger projects, one good example is the functionality provided by “partial checkouts”.
  • Last, but not least, the biggest non-technical different between Mercurial and Git is the marketing. Git seems to be better marketed these days and that clearly makes many people use Git.
devops, git, mercurial

Published at DZone with permission of Eva Johnson . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}