jj – the CLI for Jujutsu

Original Article ↗ Hacker News Discussion ↗

Jujutsu (“jj”) is presented as a git-compatible version control tool that replaces branches and staging with a simpler “changes” model, automatic snapshots, powerful undo, and easy history rewriting, while still pushing to ordinary git remotes. Enthusiasts highlight smoother workflows for stacked changes, rebasing, conflict handling, and experimentation, and appreciate that teams can adopt it incrementally alongside git. Critics counter that git’s pain points are overstated, that submodules/LFS and certain team workflows remain awkward, and that the benefits may not justify relearning core tooling for many experienced git users.

Git compatibility and coexistence

  • Many commenters value that jj uses a git‑compatible backend; you can adopt it unilaterally while teams stay on git.
  • Some report completely seamless use with git remotes; teammates often don’t notice they’re using jj.
  • Others note frictions:
    • Mixing git and jj commands in the same checkout can lead to confusing states (e.g., detached HEAD, mismatched statuses).
    • Submodules are only partially supported (must use git commands; no native management), which is a blocker for some.
    • Git LFS is not yet fully supported; work is in progress.
  • Consensus: use jj as the primary interface for a repo, and treat git as a low‑level tool when necessary.

Core model and workflows

  • jj treats the working copy as a commit/change; edits auto‑update the current change rather than living unstaged.
  • Key concepts: stable “change IDs”, anonymous branches, mutable vs immutable commits, and an operation log that lets you jj undo almost anything.
  • Typical workflows:
    • jj new to create a new change on top of some revision (often trunk).
    • jj edit to amend an existing change; seen by some as a “footgun” because it can unexpectedly rewrite history if misused.
    • Heavy use of squash, split, absorb, and interactive variants to reshape history and move edits between changes.
  • Conflicts can be committed and resolved later; rebasing doesn’t force immediate resolution.

Perceived advantages

  • Easier stacked/”chained” work: multiple dependent PRs/changes are more natural to manage and rebase.
  • History rewriting feels safer and simpler; jj undo is widely praised.
  • Reduced need for stashes and explicit staging; anonymous branches and changes serve that role.
  • Operation log and conflict handling make experimentation and refactoring less stressful.

Concerns, drawbacks, and fit

  • Some users tried jj for weeks/months and saw little practical benefit over established git workflows (often aided by tools like magit).
  • Auto‑committing model worries people who like git’s “do nothing until I say so” behavior, especially around temporary edits and secrets.
  • GitHub/PR workflows: stacked/rewritten histories can confuse GitHub’s SHA‑based review model, though newer stacked‑PR tooling and third‑party services aim to help.
  • Learning curve: experienced git users sometimes find jj’s concepts (e.g., new vs edit, unnamed branches) unintuitive; others argue jj is easier for newcomers with no git baggage.
  • Adoption skepticism is high: many see git as “good enough” and question whether jj is a big enough improvement to justify switching.