Git vs. Mercurial in 2024

Back in 2009, when I first realized I needed to adopt version control into my Access development process for the sake of my own sanity, I had a choice to make: Mercurial or Git? James Bond or MacGyver?

Git is MacGyver

In one of the seminal articles comparing Git and Mercurial, Patrick Thomson compared Git to the 80's TV character known for building bombs with little more than duct tape and bubble gum:

Git’s design philosophy is unmistakably that of Unix: unlike Subversion, CVS, or Mercurial, git is not one monolithic binary but a multitude of individual tools, ranging from high-level “porcelain” commands such as git-pull, git-merge, and git-checkout to low-level “plumbing” commands such as git-apply, git-hash-object and git-merge-file. So, like MacGyver, you can do just about anything you need with Git– this includes totally awesome Wiki engines, issue trackers, filesystems, sysadmin tools – everything short of fuse repair.

In one of the more prescient pieces of technology writing ever, Thomson foretold the coming dominance of Git and, most impressively, the proximate cause of that dominance: GitHub (emphasis mine in this and all subsequent quotes):

There is no better emblem of git’s flexibility than GitHub. GitHub’s rise to success has been positively meteoric, and with good reason. It’s a brilliantly-designed site that serves as more than a pretty, browsable frontend to my source tree in that it brings a social aspect to programming – using Git, I can fork anyone’s project, make my changes, petition for them to be included in the main repository, and pull other people’s changes to mine. Though it took a while for me to adjust to the anarchic notion of every user having their own equally-valid fork of a project – shouldn’t there be one definitive version of a project? – I realized its potential when working with other contributors to Nu. Add the fact that GitHub is one of the most solid and reliable services I’ve ever used, and you’ve got what very well might be the deal-breaker in the fight for DVCS dominance.

Boy, was it ever.  GitHub single-handedly won the DVCS war for Git.

Thomson concludes his Git analogy by basically making the case that Git is a poor fit for the typical Microsoft Access developer:

In conclusion, Git is perfect for command-line wizards, people with large teams and complicated projects, and those who need their DVCS to be endlessly configurable. Certain developers have a workflow which, when interrupted, causes much grief and lamentation – if that description fits you, then git is almost certainly what you want, because it can be molded to fit the most esoteric workflow. Solo developers and those accustomed to working with centralized VCS’s may find git to be hostile, unfriendly and needlessly complex. When I work on a large project with many committers, I prefer git and GitHub.

Maybe I'm just sheltered, but I know very few Access developers who are command-line wizards, are members of large software development teams, or even use version control, let alone need it to be "endlessly configurable."

Mercurial is James Bond

For Mercurial, Thomson chose the debonair assassin to serve as its avatar:

Mercurial is like James Bond: though they are not suited for each and every job, put them in a situation for which they are prepared and you will get things done. (If your programming job is as exciting as a Bond movie, please get in touch with me right away when one of your programmers is killed in action.)

Thomson continues:

In contrast to git’s philosophy of providing a flexible platform built out of individual components, Mercurial is monolithic and (relatively) inflexible. Developers who like to keep their system clean will probably appreciate the fact that hg installs one binary in contrast to the 144 that make up git, and developers who think that git’s ability to edit your previous commits is moronic, unnecessary, and dangerous will appreciate the simplicity hg provides by omitting that particular feature.

Monolithic and inflexible: does that sound just the tiniest bit like our beloved Microsoft Access?  

And, yes, I strongly agree that git's ability to edit your previous commits is moronic, unnecessary, and dangerous.

In conclusion, Mercurial is the yin to git’s yang: those such as myself who are constantly experimenting with new ways to work and write code will object less to the restrictions that hg imposes on workflows. After switching to Mercurial for a small two-person project last year, my collaborator observed that Mercurial feels a lot more Mac-like – usability and smoothness of operation trump Unix philosophy when necessary. If I don’t have to share my code with anyone, I tend to use Mercurial in order to get things done faster.

Does Any Of This Even Matter Any More?

Patrick Thomson published Git vs. Mercurial: Please Relax over fifteen years ago (August 7, 2008).

At the time, Git and Mercurial were very much still competing for market share.  We all know how that turned out.  (Apparently, Patrick knew how that was going to turn out fifteen years ago; bully for him!)

Oh, if you don't know how that turned out, Git won in a landslide:

Ecosystem Über Alles?

Having been a loyal TortoiseHg user for over fifteen years, I struggle mightily with this question.

How important is Git's dominance of the version control ecosystem in the context of the decision-making process for Access developers choosing between Git and Mercurial?

I happen to believe that Mercurial (with TortoiseHg) is a much better option for the typical Access developer than Git (if you set aside Git's market share):

• TortoiseHg is the best version control GUI for Windows
• Mercurial (especially with TortoiseHg) has a much lower initial learning curve than Git
• The GUI-first nature of Mercurial with TortoiseHg is a more natural fit for Access developers than the command line-centric Git
• Mercurial's never-change-history philosophy makes for a safer user experience, encouraging experimentation for new users
• Most Access developers work alone or in very small teams
• Most Access applications are written by single developers
• There are very few Microsoft Access open source projects

Now, I'll be the first to admit that those parentheses are doing some very heavy lifting up above.  When a market is split 60-40, there are some benefits to being on the side of the 60%.  When a market is split 97-1, though, there are some real downsides to being on the side of the 1%.

Which brings me back to the title of this section.

Does the ecosystem advantage–by itself–make Git the only good version control system choice in 2024 (for Access developers)?

It's certainly a compelling argument, but it's one I plan to push back on in future articles.  Stay tuned.

Cover image created with Microsoft Designer