I've used both quite a bit, first Sapling and then Jujutsu, and now I exclusively use Jujutsu and am one of the developers. I previously used Git almost every day for ~15 years. Frankly, I think you'll be very happy with either of them; they are pretty much straight upgrades from Git in most ways. Some notes (random, non-exhaustive):<p>Both of them are heavily Mercurial inspired; Sapling is a heavily evolved fork of Mercurial, while Jujutsu was strongly inspired by many of its concepts but shares no code (the two main developers, Yuya Nishihara and Martin von Zweigbergk, are former heavy hitting Mercurial developers.) They support features like revsets, filesets, have a notion of "changeset evolution" built into their internal models, and more.<p>These features actually make it possible to do things in an "open ended way" that would be difficult or not-possible to do in Git; something like finding all commits with 'description(foo) & author(aseipp)' for instance is not something I'm sure you can do in Git in a one-off way, as a counterexample to the "just run this command in Git to do that!" argument.<p>Both of them have a significantly simpler conceptual model because they replace concepts like "stashes" or "the staging area" with commits. To be clear: you can do all the things you like with Git, but with less conceptual overhead. There are fewer "nouns", and consequently fewer "verbs" you need to use and memorize.<p>They also don't tend to muddle a bunch of stuff together under one name; rebase is just rebase, not "rebase and edit commit message and reorder and throw away commits and merge commits and ..." like in Git. Or consider `git revert` and the dozen options that make it work on this-or-that. This and the previous point mean their UX is also much smaller than Git, a bit more clean and well separated, etc.<p>Jujutsu has an even <i>further</i> simplified model because it doesn't even have a concept of things like "the working copy." Everything is a commit. This has a large list of downstream consequences on things like performance (jj rebase is vastly more efficient than git rebase), internal design choices, etc but the takeaway is that you have an even simpler cognitive model. The flipside, I think, is that Jujutsu might take slightly longer to "internalize."<p>Both of them have the ability to expose the `.git` directory next to their own VCS directories (.sl and .jj) so your existing tools like showing status lines in the editor gutter can work. Jujutsu calls this "colocation", and Sapling calls it "dotgit" mode. Sapling's "dotgit" mode is still experimental; Jujutsu's colocation mode is well supported, and likely to become the default in the near future.<p>Both of them have 'undo' commands. Imagine that! A command that can undo your mistakes! Users are almost always universally filled with joy when they discover this feature.<p>Both make workflows like stacking or rebasing a lot easier, conceptually, so you will probably be happier with either. Sapling has ReviewStack so you can do stacked reviews a bit more clearly on GitHub. For Jujutsu we don't integrate with ReviewStack, or Reviewable/Graphite (yet), so you are still at the mercy of Github's review tools, which are a bit weak when it comes to interdiffs/stacked PRs.<p>Sapling has a command called "interactive sapling" or "isl" which is a web-browser based GUI that you can use to drag and drop, reorganize, split, restack commits with ease. isl is an incredible tool, it is easy to use even for newcomers, and I consider it a major advantage over Jujutsu!<p>Jujutsu has the notion of "first class conflicts" which make most forms of conflict resolution far easier. It's a bit difficult to explain but think of `git rerere` combined with `git rebase --update-refs`, but on steroids. I consider this to be a major advantage over Sapling.<p>Sapling is the VCS of choice at Meta, and they are working on making the scalable server-side components available too. Jujutsu is designated to (hopefully) become the true successor to 'fig' at Google, which I suspect you're familiar with. Maybe this matters to you as a former Googler, but maybe not. (Note: I do not and have never worked at Google, but Martin does and is the leader of this effort.)<p>Jujutsu actually exposes a set of APIs so you could in theory use it with other backends; that is how the Piper/CitC integration at Google works, and people have floated ideas like a Mercurial backend, for instance. In theory it is extensible, but this might not matter to you.<p>Jujutsu is a pure Rust codebase, having been written from scratch, while Sapling has a much longer history; it is a mix of Python and Rust. I personally think this makes it much easier to contribute to Jujutsu, and it was one of the reasons I switched because I personally tend to write patches for tools I use. OTOH, Sapling is much more refined in some ways. It is up to you if you think this matters.<p>Compatibility-wise, I believe Sapling uses `git` commands underneath to drive a lot of its features, while Jujutsu instead uses libgit2/gitoxide for interop. IMO, libgit2 has caused us and users a few issues long-tail issues that are hard to resolve; things like Git Credential Manager or OpenSSH config support for instance don't work as well with libgit2, which causes annoying bugs. Other features like partial clones don't work (shallow clones do.) You can just use `git` commands to work around this, typically, but I think Sapling might handle some of these quite a bit better.<p>In short, I think you'll probably be happy with either of them. If you have any questions about Jujutsu at least, you can open them on GitHub, Discord, IRC, etc.