As somebody who has actually been using Sapling (because it provides a much saner UI and mental model than git), the git compatibility of Sapling is at best so-so. It feels more like a stopgap solution while they're evolving their own backend (which I'm pretty sure they use internally, because git just doesn't scale to FB monorepo size and doesn't support their rebase-on-push operation). LFS flat-out doesn't work with Sapling. Force pushing after an amend or rebase is still cumbersome, because you need to explicitly specify (again) the branch you are pushing to. And I'm not sure how bad the file descriptor problem still is that you have (had?) with large repos or submodules [1]; there was a new release recently, but I haven't actually stress-tested that.

[1] At least some of that may be due to file descriptor leaks: https://github.com/facebook/sapling/issues/464

Meta's fork/rewrite of hg, Sapling hasn't gone anywhere yet because it needs EdenFS and Mononoke that aren't yet/maybe never FOSS. It's only called hg internally because of legacy reasons but it's completely different.

Microsoft hired a git maintainer to improve large repo performance and so it's better than it was.

Git has a lot of warts, but if I were to pick an alternative it would be Fossil, not Mercurial.

I believe Meta’s implementation includes server components (Mononoke) that were not open-sourced, or at least not buildable without closed-source dependencies. Same with Microsoft’s fork of git that relies on a virtual filesystem, but that one is open-sourced, if for Windows, not Linux.

And Google has been putting much of their investment behind jj.

One other interesting thing I've noticed, mercurial has stopped building windows standalone releases. It's been that way for around 9 months.

The day-to-day workflow at Meta is still using the hg frontend and regular hg commands. I would love to see the git frontend used instead, but, it hasn't happened yet.

> Mercurial is over.

I mean to be fair so is Firefox