Jujutsu (jj), a Git compatible VCS

Original Article ↗ Hacker News Discussion ↗

Baseline: Simple Git Workflow & Skepticism

  • Several commenters say their Git workflow (branch → commit → rebase → push → PR) is “lightweight” and not a daily hindrance.
  • Skeptics ask why a whole new VCS is needed instead of improving Git, or building better UIs on top of it.
  • There is concern about perceived extra verbosity/complexity in jj, and about fragmenting tooling around an entrenched standard.

Perceived Advantages of Jujutsu (jj)

  • Tracks merge conflicts as first‑class data, intending to avoid re-resolving the same conflicts and eliminating Git’s many “special states” (rebase, merge, am, stash, etc.).
  • Models the working copy itself as a commit; there is no separate index or stash.
  • Every command effectively snapshots work-in-progress, making it easy to branch off experiments or recover previous states without manual WIP commits or stashes.
  • Conflict resolutions and other history edits are normal commits that can be rebased, diffed, and shared, unlike Git’s local-only rerere.

History Editing, Stacked Changes, and Everyday Work

  • Strong advocates highlight painless editing of earlier commits, even when later work depends on them; downstream changes auto‑update.
  • This especially benefits workflows with stacked PRs, long review cycles, and frequent feedback-driven rewrites.
  • Switching between multiple lines of work (hotfixes, multiple PRs) is described as simpler: no need to juggle stashes/WIP commits; “everything is already committed.”

Workflow Simplification Claims

  • Fewer conceptual states: only committed changes, with a special “current” commit (@) instead of dirty/staged/committed.
  • Many Git pain points cited: rebase conflicts, stash conflicts, accidental WIP pushes, “broken” intermediate states that require expert rescue.
  • Some users report becoming productive with jj in a day and finding it “simpler and more powerful.”

Auto-Adding & Ignored Files

  • jj’s default of auto‑adding changes (including untracked files) is divisive.
  • Critics worry about polluting history with temporary files; proponents say it forces better ignore discipline and is easy to fix by editing the commit and letting descendants auto‑rebase.
  • Auto-adding untracked files can be configured off; tracking changes to already‑tracked files is fundamental.

Git Compatibility, Adoption, and Alternatives

  • jj can use Git as a backend; teams can interoperate with Git users without repo migration.
  • Some argue even a 15% improvement may not justify retraining costs at industry scale; others counter that long‑term gains and optional adoption mitigate this.
  • Comparisons are made to alternatives like fossil and pijul, and to Git UIs (e.g., TUI frontends) that already improve workflows on top of Git.
  • A few report getting stuck or confused in jj, viewing both Git and jj as still too complex and error‑prone.