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.
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.
Sapling can use Mononoke, but it can also use Git repositories as the underlying storage layer with no server at all, and it does so by default in the OSS build. You can use it just fine with GitHub today, but there are rough edges.
My understanding is that the work to support OSS builds of Mononoke+EdenFS is happening, but there's no exact timeline right now because (from what I can tell) they basically have to abstract out and write new production storage components for the metadata/object layer, as they can't use their internal ones, obviously.
I’ve been using the sapling CLI as my frontend with github as my backend and finding it quite delightful - all the UX niceness from mercurial (and then some), while still being totally compatible with the rest of my team :)
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.
Mercurial is dead unfortunately. It's been stuck on Python 2. The CLI was saner than Git but it needed Python, which helped with our (better) decision to pick Fossil instead. This was 11 years ago. It's been great, it has everything you need in a single executable which can be statically compiled.
> Mercurial is dead unfortunately. It's been stuck on Python 2.
Mercurial adopted Python 3 a while ago. Not to mention, huge chunks of it have been rewritten in Rust.
Mercurial has continued to get new features like Changeset Evolution [1] that once you use it, you wonder why all version control systems don’t have it.
Mercurial runs on Python 3 just fine and has been for a while. In fact, starting with Mercurial 6.2 (from July 2022), Python 2 is no longer supported [1].
I did not use them because I am on linux only, but I see that Matt is active and responsive, both on the mailing list and chasing bugs on the issue tracker on heptapod ( https://foss.heptapod.net/mercurial/tortoisehg/thg )
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.
While the real sl (Steam Locomotive) isn't installed on that many systems, I can only imagine the annoyance that it must bring to any former Facebook engineers when they assume that it's the version control
Mercurial is over.