[forrestthewoods]

> automatic working copy snapshots

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”.

[sunshowers]

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.)

[forrestthewoods]

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.

Don’t think I understand what this means.

[sunshowers]

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.