I spent easily 10 000 hours using Mercurial over nearly 10 years. I was, and still am, a huge Hg fan. I switched to Git quite late (some time in 2018) and converted all projects, both home+work, cold turkey. I recently revisited an old Hg project. It was really nostalgic. Hg is easier to use and TortoiseHg is the best GUI for SCM bar none.
But Git is simpler. The simplicity is a mind-opener. Git deserved to win. When you want to do something in Hg that’s not built-in - even something like rebase - all the 30+ included extensions are all marked as “EXPERIMENTAL” and you can only safely interact with the data model by writing a custom Python 2 script.
With Git you can go into the .git directory and delete a refs file. Filter-branch is a first-class feature. A few basic concepts underpin more functionality. There are genuine multiple implementations. This is radical transparency.
Originally I thought I would have missed having draft phases, embedded branch names, and ordinal commit numbers. But in practice I don’t miss these at all. And in retrospect these all actively work against code-sharing in general, and the pull-request model specifically with its working revisions. Git is inherently more social-capable and will always have a stronger network effect. Hg does not have separate author + committer.
With Git you can stage individual lines, not just hunks. This alone should be reason to use Git over Hg (oh, you can enable the optional crecord extension and do everything from the CLI? that’s not Hg’s famed ease-of-use).
I once started to develop a Gogs/Gitea clone for Hg. For compatibility it had to communicate by IPC with a standalone Python process, then I hit a roadblock because the wireproto was undocumented for bundles. Hg developers were also not enthusiastic about my proposal to switch from full+diff storage to chunk storage.
I do miss some things. A central .hgtags file would definitely resolve some tag conflicts and issues with coworkers re-pushing deleted tags.
Originally posted on [1]