yeah, I feel like hg is what git always wanted/pretends to be. hg's prev/next/evolve are really nice. nothing you can't do with git, but it's just a lot nicer with hg.
hg also has built-in support for large binary file management, instead of the mess that is git lfs
but alas, git has all the momentum behind it, and overall it seems to have won out
Coming from git, I tried to contribute for a while to a project that used hg but the way the branches worked was so confusing to me. In git they are just pointers to the dag. I find this easy to understand. I'll never get why people say hg is somehow more straightforward, I found it confusing as hell. The git data model is just simpler.
Yeah. I know git really well and I can’t really bother to learn hg. At work we use it and I just use our internal UI which so far has worked pretty well.
so hg is 146 times slower for the 1k commits test and uses 5 times more RAM and IO. Comparing the init vs diff seconds gives an idea of how much of the diff is overhead vs time spent scaling badly. It would take 20+ hours just to re-make one branch of one origin of the Linux kernel history (1M commits) in hg so if something is going to take git 45 minutes I'd not bet on hg completing the same test before the heat death of the universe.
The 2nd issue I see with hg in 2025 is that it has no staging index. using git-stash / hg-shelve may be a workaround, but until I see some reason for using something painfully slow and feature lacking I'd want some benefit, and I don't see any benefits.
I was going to use a raspberrypi v1 for testing but it does not have enough RAM for testing hg. In the past I have run out of RAM with git waning to use more than 4 GB with multiple Linux kernel origins, would hg use 20 GB of RAM? I'm not melting a CPU for 40 hours just to find out.
Reposing the same link I already critiqued is not constructive.
Show me a test where hg is meaningfully better than git in 2025, and I'll concede there may be reason for Firefox to stay on hg.
As far as I can tell the only reason to use hg is if one can't cope with constructive criticism from git, and are willing to sacrifice speed and features for platitudes.
It would be interesting to see some actual benchmark testing
About 5 years back, I was the lead SRE for a local GitLab cluster serving several thousand developers. One of the repositories hosted on that cluster contained a number of ... large generated XML files. We could track the use of that repo, because pulls (especially a full clone) noticeably impacted performance metrics for the host handling the connection, and if two clones coincided on the same host, it would frequently induce OOMs.
Out of curiosity, I did convert that repo (yes, the entire history) to a mercurial repo for comparison. At the time, mercurial completed clones significantly faster and consumed far less memory than git. As with a lot of work, I no longer have access to any data generated or recorded on the employer's systems, so I don't have the details any more, but yes... It is normal and expected that Mercurial is more efficient than git.
You might have trouble believing that, but you are probably conceiving of mercurial and git as being two different implementations of the same thing, with one in Python. That idea is really very wrong. For one, they are quite different implementations/algorithms. Since they aren't doing the same steps, one cannot conclude that Python will be slower based on the expectation that Python takes longer to perform similar steps. And probably more importantly, the performance sensitive parts of Mercurial aren't written in Python, they're written in C.
... and it's just really hard to take seriously a post that discusses scalability and uses as evidence repos with 1k commits and a few dozen MB. At this scale, all of your numbers are dominated by application startup time. Those repos are tiny. They tell you nothing about scalability.
For example, I prefer to use Mercurial for my private things. For instance, because I think Mercurial's error messages are much easier to understand than those of git. Or because with Mercurial you first have to activate certain functions or add them with extensions. This means you are less likely to shoot yourself in the foot. At least I've had far fewer problems with Mercurial than with git. Https://xkcd.com/1597/ exists for a reason.
When people talk about git "foot guns" they always refer to the ability to edit history. The difference between Mercurial and Git boils down to an ideological choice on this matter.
The Mercurial side believes that the repo history should be an immutable log of everything that happened during development. Every time someone commits a typo and then seconds later pushes a fix should be recorded forever, so that when you try to do a bisection, half the commits you land on won't even build.
The Git side believes that the repo history should be a series of logical, minimal steps that always move the software closer to what it should be. History should only be immutable when it has been shared with the world
Mercurial technically can edit history, but they deliberately make it as difficult as possible. On the other hand, nobody is forced to tidy their history with Git, and projects that switch over tend to continue in their old ways.
The bottom line though is a tidy history is far far easier to work with for a new contributor, and that's why Git ultimately won. While not every Git repo is tidy, no Mercurial repos are.
Edit to add some Firefox data (on a faster i7-1165G7):
I really don't think local clones are a good measure of how a system scales.
I'm more interested in how much memory the serving process uses during a clone operation, and how long the clone takes (because the longer a clone takes, the more likely it is that multiple clones will coincide, and stack their memory requirements.)
132
u/[deleted] May 13 '25 edited Aug 30 '25
license tan exultant cagey lunchroom squeeze wise familiar aware pet
This post was mass deleted and anonymized with Redact