The command line interface for Sapling called `sl`, which is Git compatible, is fully supported by the team at Meta. You can file bugs and feature requests, etc, though the repository is a bit intimidating. It is only the non-Git server components (Mononoke, EdenFS) that are not yet really supported [1] but I think most people aren't really concerned with that, when writing a post like this.

For all intents and purposes, Sapling works very well, I think, and in some places it has a lot more polish, like the "isl" graphical interface, which makes things like rebasing and restacking incredibly intuitive even for new users. (I consider isl to be a significant advantage over Jujutsu, and I say that as a Jujutsu developer!)

[1] Though, Mononoke does support features like exporting Git repositories to remote hosts from the internal model; that's not really what people are looking for in a lot of cases though.

What's the advantage of using Sapling as an alternative Git frontend?

You don't need to manage the stash or index, those are just expressed as commits, so you have fewer commands and a simpler UX, and can use universal tools like 'split' to handle cases you'd otherwise need stash/apply/switch to handle.

It supports Mercurial-like "revsets", so it is easy and flexible to query the commit graph for all kinds of information, in a user-controlled way.

Features like 'sl absorb' can do git 'fixup commits' automatically.

It supports a notion of changeset evolution, so if you have `A -> B -> C` and `A` gets merged into main, it will automatically rebase `B -> C` on top (among other things).

"isl", the "interactive sapling" GUI, is absolutely stellar and I don't think there's a faster way to do tasks like 'rebase X onto Y' or "reorder commits in stack Y" than that, even with Jujutsu.

It comes with integration for a tool named ReviewStack so you can do stacked code reviews while working on GitHub.

There is an undo command to undo your mistakes.

And, while I'm not sure this is in the Git backend today, many algorithms like getting the history of a file are O(N) in terms of file history as to the history of the whole repo (e.g. try `git log file` in gecko-dev or Linux and it is slow.)

Many of these advantages (not all) are shared with Jujutsu, to be clear.

> You don't need to manage the stash or index, those are just expressed as commits,

You can also avoid managing the stash in Git. By not using it.

But you still need to deal with a dirty working copy somehow. This blog post from today happens to describe one scenario where it's nice not to have to worry about changes in the working copy:

https://drewdevault.com/2024/12/10/2024-12-10-Daily-driving-...

Seems to have been deleted: "404 Page not found".

Just the name makes it a no-go for me, it would interfere with my favorite command-line utility, `sl` - Steam Locomotive

https://github.com/mtoyoda/sl

> The command line interface for Sapling called `sl` [...]

This is a really unfortunate choice of the binary name - it collides with a classic UNIX utility. I use it everyday and it would be very annoying for the program to do something unexpected.

Edit: apt install sl

The package name will be sl-vcs like chromium-browser

Pijul's "upstream" (and git predecessor) darcs is still useful today. It doesn't see itself as a "research prototype" and has decades of experience in the real world. It isn't git compatible but does offer a fine fast-export to git in the worst case you need to switch.

Unfortunately some of those decades of experience with darcs are lessons in how it performs poorly in large repos or with large teams/lots of merge conflicts, but that still leaves darcs a good experience for small projects and "just getting stuff done".