Sapling is great. I worked on it for many years at Facebook and I think we did a pretty good job building a workflow that most developers preferred to Git.
To the extent that Jujutsu is similar to any other systems, it is most similar to Sapling — both have a Mercurial heritage (Sapling is derived from hg, while Jujutsu is a new codebase with an hg-inspired UX). However, Jujutsu introduces a number of fantastic improvements over Sapling, such as first-class merge conflicts and automatic working copy snapshots. See my testimonial, the top one on this page:
I no longer do VCS development, but I'm a very happy full-time jj user. I've also helped onboard a number of people onto it.
(Personally, I'm just happy that after the dark era of Git's branch-first UX being dominant, the anonymous heads/commit-first UX pioneered by Mercurial is making a resurgence. The vast majority of developers prefer a commit-first UX, and it is so much easier to explain things like stacked commits if you don't have to introduce git rebase -i.)
One of my favorite things about Sapling is that all commits are automagically backed up to the cloud. The D in DVCS is not important for roughly every project ever. So I’m not sure how to feel about “every state is a commit”.
I'm not sure why you think the two are incompatible? Commit Cloud is pretty great but makes more sense in a corporate environment. You don't have to upload every automatic commit that gets made locally, though you could choose to if the capacity requirements work out.
The automatic snapshots provide a great degree of UX coherence — definitely more than Sapling currently does. (When I last chatted with the Sapling folks, they were quite interested in porting some Jujutsu features over to it.)
Uploading everything everytime someone runs jj status seems potentially burdensome. Uploading on every commit is maybe also burdensome but at least it’s also nice and explicit? I dunno maybe it’s fine! Or maybe some heuristic would make it fine enough. I don’t really get the “working copy commit” concept. It hasn’t clicked yet.
> The automatic snapshots provide a great degree of UX coherence — definitely more than Sapling currently does.
Try jj out on an open source Git repo -- I think it will both be very easy to pick up, since you're used to Sapling, and quickly make sense.
You know how sl amend and sl fold/squash are two different commands, right? Well, jj amend is actually an alias for jj squash. And that's just the beginning.
Regarding uploading, yeah, you'll likely have to have some heuristics, but Mononoke is generally built for very high throughput. The heuristics might just be around local debouncing and aggressive expiry of uncommitted snapshots in the cloud. But in general, it's worth thinking about the local moment-to-moment UX independently of commit cloud considerations.
To the extent that Jujutsu is similar to any other systems, it is most similar to Sapling — both have a Mercurial heritage (Sapling is derived from hg, while Jujutsu is a new codebase with an hg-inspired UX). However, Jujutsu introduces a number of fantastic improvements over Sapling, such as first-class merge conflicts and automatic working copy snapshots. See my testimonial, the top one on this page:
https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us...
I no longer do VCS development, but I'm a very happy full-time jj user. I've also helped onboard a number of people onto it.
(Personally, I'm just happy that after the dark era of Git's branch-first UX being dominant, the anonymous heads/commit-first UX pioneered by Mercurial is making a resurgence. The vast majority of developers prefer a commit-first UX, and it is so much easier to explain things like stacked commits if you don't have to introduce git rebase -i.)