jj: a Git-compatible VCS that is both simple and powerful

Original Article ↗ Hacker News Discussion ↗

Motivation and Goals

  • Many commenters see jj as “Git 2.0”: same underlying power, fewer concepts and less incidental complexity.
  • Main target pain points: confusing Git states (staging, stash, rebase modes), fragile/annoying history editing, and multi-branch/stacked-PR workflows.
  • Some are motivated simply by curiosity and recommendations from trusted colleagues; others by frustration with Git’s UX despite understanding it well.
  • Critics argue Git already solves their problems well enough and see jj as “different not better,” or a solution in search of a problem.

Core Model and Key Features

  • jj distinguishes changes (mutable, user-facing units) from commits (immutable backing snapshots, often Git objects).
  • No special staging area or stash: “staging” is just another change; temporary work is just WIP changes.
  • Automatic rebasing of descendants when earlier changes are edited; conflicts are first-class and can be fixed later rather than blocking workflows.
  • Revset language and templating provide expressive ways to select and operate on subgraphs of history.
  • Operation log (op log) and undo allow reverting any prior repo state, not just recent HEAD moves.

Perceived Workflow Improvements

  • Easier stacked PRs and multi-feature work: editing earlier changes and having everything restack automatically.
  • History cleanup becomes routine: split, squash, edit and interactive splitting are reported as smoother than Git equivalents (especially vs rebase -i and add -p).
  • Frequent auto-snapshots mean “all changes are recorded” locally; users feel freer to experiment.
  • Some say jj essentially replaces large chunks of Git’s “Undoing Things” complexity with one conceptual undo.

Concerns, Skepticism, and Limitations

  • Some find constant implicit changes and dual ID sets (jj change IDs vs Git hashes) confusing, especially with IDEs that only show Git commits.
  • Fear that jj’s mutability makes repos easier to “mess up,” especially when editing deep history; others counter with immutability rules and undo mechanisms.
  • Rebase-centric, mutable-patch workflows spark philosophical debate; a vocal group argues rebasing itself is harmful and that jj doubles down on it.
  • Large binary files and LFS-like behavior are currently a weakness; auto-tracking big files is seen as a potential repo-bloating footgun.

Tooling, Ecosystem, and Adoption

  • jj interoperates with standard Git repos and forges (GitHub, Azure DevOps); many use it locally while teammates stay on Git.
  • Some complain about poor IDE awareness (e.g., “detached HEAD” views) and want native jj integrations or GUIs.
  • Comparisons with Sapling and Mercurial: similar ideas (revsets, better UX), but jj emphasizes Git compatibility and a simpler internal model.
  • Several commenters use jj daily and “won’t go back”; others tried it and prefer Sapling or plain Git due to habits and tooling.