undefined | Better HN

0 pointsmartinvonz3y ago0 comments

I think those two things that arxanas mentioned are the biggest differences (i.e. working-copy-as-commit and conflicts in commits). I haven't used Sapling, but I suspect Jujutsu has better support for moving commits (and parts of commits) around without touching the working copy.

Sapling, on the other hand, has much better support very large repositories, since they've spent a lot of time on that over the years. We're going to copy some of Sapling's solutions to Jujutsu soon, since we're working on integrating it with Google's monorepo (slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX..., recording: https://youtu.be/bx_LGilOuE4).

0 comments

3 comments · 3 top-level

arxanas3y ago

Yep — after trying out Sapling, it aborts many operations due to working copy changes, which I now find to be jarring interruptions to my workflow. Jujutsu (and even git-branchless) have much better support for juggling working copy changes, which is invaluable in a patch-stack workflow.

The Sapling support for remote repositories was a little rough in my opinion. Jujutsu and git-branchless can both co-locate with the Git repository, so you can always drop down to Git commands if there's something you're having trouble doing. (I find the `jj git` commands to also be better at interacting with remotes for now.)

martinvonzOP3y ago

Oh, in the context of Sapling, I should say that Jujutsu runs the equivalent of `sl restack` after every command. Thanks to first-class conflicts, that always works.

ironfootnz3y ago

I see a few issues on their approach for working copy and log search. Let me try out and see if I'm right on my assumptions.

j / k navigate · click thread line to collapse