Popularity of Git/Mercurial/Bazaar vs. which to re

Question

Going by the number of questions on this site for these three distributed version control systems, it seems like Git either

1. is more popular, or
2. is more difficult (hence requiring more questions), or
3. has more features (hence requiring more questions).

Or most probably a combination of the three. (Let's say that popularity on this site equates to popularity at large.) Here are the numbers:

It's not entirely satisfactory having three competing yet largely equivalent open source products to choose from. Personally I use Git and I'm fine with the other two. But when it comes to recommending one system over the others, I'd like to ask: can we start recommending one safely yet?

Comments from mid-2009: The recent historical popularity of Subversion is clearly reflected by the number of questions, indicating at least a small tipping of the scales towards Git over the Mercurial or Bazaar.

Comments from mid-2010: Look at that huge relative increase in Mercurial numbers. Obviously only two-data points aren't enough to show a trend, but it looks like Git and Subversion are largely entrenched, Mercurial has seen a lot of growth, and Bazaar has remained relatively quiet.

Brief comment, mid-2011: Can we just call Git the winner? :) No, I accept the argument that number of questions is not equivalent to popularity. Numbers sure are strong, though.

---

Code to reproduce the above plot:

import datetime as dt
import matplotlib.pyplot as plt


dates = [
    "01/06/2009",
    "01/07/2010",
    "01/07/2011",
    "01/07/2012",
    "01/07/2013",
    "01/07/2014",
    "01/07/2015",
    "01/07/2016",
    "01/06/2017",
    "28/08/2018",
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]

git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525]
mercurial = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765]
bazaar = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539]

ax = plt.gca()

ax.grid()
plt.plot(x, git, label="[git]")
plt.plot(x, svn, label="[svn]")
plt.plot(x, mercurial, label="[mercurial]")
plt.plot(x, bazaar, label="[bazaar]")
plt.gcf().autofmt_xdate()
plt.ylim(0)

plt.legend()

# plt.show()
plt.savefig("comparison.png", transparent=True, bbox_inches="tight")

Answer 1

Well the reason that git has so many users is that the Linux kernel uses it, so if you want to do Linux development, you use git.

Since so many people are involved with git, I'd recommend using git, simply due to the larger user base. In fact, the numbers you show above are a clear sign of this.

As for difficulty, all version control is difficult, especially the distributed kind. SVN and CVS weren't exactly easy (for me at least) at first glance. This is just part of the necessary learning curve of getting used to a version control system.

EDIT: Since you added a subversion reference, I figured I'd address it. I think most people will use svn because it has all sorts of pretty GUI interfaces for it. In general, people hate to use the command line, including some developers. git typically does not work very well on Windows either (or at least not as seamlessly). Since many people are on Windows, this kills the number of potential users.

In addition, I think the concepts of SVN are a little easier to grasp since svn uses a central repository rather than a distributed system. It's easier to understand, "Here is the big mountain of code, please add your code here," than "Here is some code, mine might be different from his, his from hers, but you can add something if you wish."

In my opinion, svn has a much better system of documentation set up. git's documentation is targeted to a little bit higher level of knowledge (of the program, not a programmers intelligence) and so makes sense after you use the system, but when first start, it just looks like a bunch of gobbeldy-gook.

Overall, I think svn is and will always be more prevalent because its general operating concepts are easier to understand, the tools are easy to use, and it has wonderful support on Windows.

Let me end with my final two cents though and say that I much prefer git because I think it's much more powerful than any other system I've used. Climbing the learning curve definitely pays off once you begin to understand the program better.

Answer 2

I don't normally post but..

I've tried git,bzr and few others i forget and found bzr has one very very weak point. For large files it insists on loading the whole file into memory. This creates issues for large binaries.

Git was a lot better in that regard. As for the difficulty. I use git in windows from the git bash. Works great and learned in less than a week (that included actual work and experimenting with other VCS)

Answer 3

In my experience judging from the number of questions noticeably skews the comparision to git and against Mercurial. The reason is twofold:

1. Have a look at hg update --help versus git checkout -h and git --help checkout. With Mercurial I seldomly found questions which aren’t answered by a few glances at hg help.

2. Check the Mercurial Wiki — if you need help, you’ll likely find it there, including many Tipps and Tricks: http://mercurial-scm.org/wiki/TipsAndTricks

Answer 4

Since the origin of social coding with Git at GitHub, Git seems to have attracted lots of followers.

Answer 5

Update November 2011:

Git is now much more mature compared to 2009:

• smart http is now supported, which means you can offer to your client https protocol to pull/clone and push, with authentication able to interface with an LDAP (important for user in an enterprise)
• A mature authorization layer now exists with Gitolite, which means you can provide isolation for "confidential" repository (again, important for large companies).
• The Windows support which was already there in 2009, is still going strong, and TortoiseGit is quite stable
• The integration with IDE like Eclipse is in progress (most of Eclipse projects are now on GitHub)

However, installing Git in a centralized environment is not trivial:
See "Distributed Version Control Systems and the Enterprise - a Good mix?"

---

One point consistently missed is:

they are different in their nature.

• SVN is a REVISION system (it stores branch and tag through cheap copy only! Merge support is not very efficient), and it is centralized.
• Mercurial or bazaar are FILE VCS (they store versions of files), and distributed.
  Arne Babenhauserheide amends that for Mercurial by pointing out that Mercurial’s History model tracks content-changes, with file-paths re-used in the storage layer to optimize filesystem access.
• Git, and that is very hard to grasp, is a CONTENT VCS (it stores delta of content, not the file itself: two files with the same content will be stored only once)

That means:

• if you have a simple merge workflow, in a single development location, stick with SVN
• if you have several development places, a distributed VCS is more adapted.
• if you have a complex merge workflow, any modern VCS is better than SVN which struggle to keep merge informations at the right places for years. It then depends on the tools (Mercurial has a more advanced Windows support for instance)
• if you have mainly text file and not too-large binary files, Git is excellent, provided you are aware of its limits.

Answer 6

An interesting blog post from Eric Sink about them all.