jj – the CLI for Jujutsu

Original Article ↗ Hacker News Discussion ↗

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.