Jujutsu for busy devs

Original Article ↗ Hacker News Discussion ↗

Perceived Advantages of Jujutsu (jj)

  • Model is described as both simpler and more powerful than git: no modal states, “everything is a commit/change”, fewer special cases (stash/index, rebasing modes, etc.).
  • Universal undo via the operation log: any repo operation (including fetches, rebases, bad conflict resolutions) can be undone or revisited; viewed as strictly nicer than git’s reflog.
  • First-class conflicts: rebases/merges always “finish”; conflicts become objects you can resolve later, in any order, without blocking other work.
  • Automatic rebasing of descendants and mutable history: changing an earlier revision transparently updates dependent work (stacked PRs, megamerge workflows) with far less manual rebase pain than in git.
  • Easy splitting and reshaping of work: jj split, jj squash -i, and jj absorb make carving a big WIP into many small, focused commits or moving changes to the “right” ancestor revision trivial.
  • Revsets and filesets allow concise, scriptable queries over sets of revisions and files, enabling workflows (e.g., repo rewriting, megamerges) that are tedious or fragile in git.

Workflow Differences vs Git

  • No dedicated index: default is that the working copy is always tracked; users emulate staging via parent commits and split/squash, or disable auto-tracking in config.
  • Non-modal operations: you can “leave in the middle of a rebase,” switch tasks, and come back later in a uniform way.
  • Encourages many small, independent changes and stacked/parallel work; advocates claim this makes PRs far smaller and easier to review.

Skepticism and Pain Points

  • Many experienced git users say git “works well enough” and see jj as solving problems they don’t have; switching cost and new mental model (revsets, change IDs) are cited.
  • Some tried jj and returned to git: reasons include performance on large repos (partially mitigated by filesystem monitors), auto-staging semantics, dislike of default jj log UI/colors, or missing ecosystem features (gitattributes, git‑lfs, git‑crypt, auxiliary git tools).
  • Concerns around auto-recording all local changes (including potential secrets or local-only tweaks) into jj’s history.

Adoption, Tooling, and Ecosystem

  • jj interoperates with git (colocated repos); can be used unilaterally in git-based teams, including Gerrit and large monorepos backends. Public/pushed changes are treated as immutable by default.
  • Popular tooling around jj includes the highly-praised jjui TUI and various Neovim plugins; some request richer GUIs and more beginner-oriented, non-git-centric tutorials.
  • Meta-discussion notes strong evangelism: fans liken git users to “Plato’s cave,” while others push back on the tone and emphasize that git plus good tools (Magit, lazygit, git-branchless, Graphite) already cover their needs.