Cited on HN 4 times, 2022–2024, never outright recommendedscore 0
Years with an HN recommendation, 2007–2026
HN links it as the canonical talk on Jujutsu's design, especially conflict handling.
Martin von Zweigbergk presents Jujutsu (jj), a Git-compatible VCS with undo, anonymous branches, first-class conflicts, automatic rebasing, and the working copy as a commit. He also covers plans at Google.
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: [link] , recording: [this video] ).
Jujutsu talk about integrating with Google's monorepo.
Jujutsu started as author's personal project and now author's full-time project at Google. It's presented at Git Merge 2022: Jujutsu: A Git-Compatible VCS - Git Merge 2022: Video: [this video] Slides: [link]
I completely rewrote the README recently to be more "user friendly"; does it address some of your question? I'm not trying to be snarky, I'm genuinely interested in if the README is now tantalizing enough to make you interested: [link] But in short, it has a better UX than Git by a mile while remaining interoperable at the storage level, so you can use GitHub; it has many of the niceties of Mercurial's UX like revsets, no staging area, and a templating language for log output. Conflict resolution and rebasing is clean, easy, and nearly automatic. It has features neither support, like a real undo command and "operation log"[1]. The UX is smaller and conceptually cleaner; fewer "verbs" that operate on less "nouns", so many things are more regular. It is available as an API (Rust crates) so you can extend it naturally to handle your own workflow, without monkey-patching things. You could even use Mercurial itself as a storage backend, or a custom, centralized server like Google does. Most importantly though, its internal "automatic snapshot model" design is quite elegant and makes the design and internals very clear. And storage system is completely independent and abstracted from this, and many of the other algorithmic details (Git sort of intertwines the data model, the algorithms, and the UX in various ways.) Features like hg changeset evolution, git rerere, and rebase --update-refs are all obsoleted and naturally handled by this design, among other things. Martin, the lead d
I think this was the talk: [this video] I would like to know more about the first class conflict handling. That could potentially be useful for an application I have in mind but I need to understand the algorithms better. How does it compare to CRDTs or other merge strategies?
Talk on Jujutsu and first-class conflict handling.
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
4 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Read more