Switch to Jujutsu Already: A Tutorial

Original Article ↗ Hacker News Discussion ↗

Practical limitations and integration issues

  • Lack of Git submodule support is a hard blocker for some; they must fall back to pure Git for such repos.
  • GPG/signing with security keys is described as painful: jj re-checks signatures frequently, prompting for hardware keys, and lacks Git’s defaultKeyCommand‑style flexibility.
  • Git-based tooling (e.g. GitLab CLI, GitHub PR workflows) often break because jj leaves Git in a detached HEAD or nonstandard state; some users see many conflicts after merges or squashes via GitHub.
  • Mixed jj/Git usage can produce many unreachable objects, making Git operations slow until manual gc is run.
  • No support yet for some workflows like git rebase -x or git‑lfs; this excludes certain lint/format pipelines and large-file setups.

Perceived advantages of Jujutsu

  • Workflow is described as “Play-Doh”: easy to constantly create, reorder, and refine small commits, then shape them into “perfect boxes” with little friction.
  • Rebase is a major selling point:
    • Can rebase trees of commits and update bookmarks automatically.
    • Easily move or split parts of a stack, parallelize branches, and reorder ranges.
    • Keeps going through conflicts (“committable conflicts”), allowing resolution later.
    • Handles merge commits and conflict reuse better, and is much faster by avoiding unnecessary working-copy updates.
  • Strong support for stacked/chain PR workflows and “clean history” practices (e.g., retroactively fixing typos in the original commit).
  • Powerful revset/template languages, global undo/restore of any repo state, and easier mental model for some users than Git’s index/stash concepts.
  • TUI/Emacs frontends (jjui, jj-mode) are praised for making the model more approachable.

“Git is fine” camp

  • Many commentators say they rarely need more than ~5 Git commands, are comfortable with stashes, worktrees, interactive rebase, --fixup/--autosquash, reflog, and see no missing capabilities.
  • Some argue complaints stem from not understanding Git’s DAG model; once you see commits as a graph and branches as pointers, Git’s behavior “clicks.”
  • For these users, jj feels like different syntax for workflows they already manage in Git, with added learning and tooling costs.

Learning curve, UX, and messaging

  • Several enjoy jj after a brief adjustment, but others bounced off due to the new mental model and command set.
  • Some find jj’s proponents and the article’s “if you don’t like jj you’re wrong / I don’t get git” tone off‑putting or “cultish,” especially when used as an argument instead of concrete feature comparisons.
  • There’s pushback against the idea that “git is too hard” is a bad reason to seek alternatives; others insist developers must deeply learn Git since it’s ubiquitous.

Advanced workflows and scaling

  • Advocates highlight workflows that are impractical in Git: heavy rebase-driven, stacked-commit development on main, large chains of review commits, and “always clean history” without rebase pain.
  • Some report jj scales fine to multi‑GB monorepos, with Git still available as a fallback for slow commands like blame.
  • For users happy with linear, simple Git workflows, these advanced patterns are seen as solving problems they don’t have.