I see a future in jj

Original Article ↗ Hacker News Discussion ↗

What jj is (and initial confusion)

  • Several readers were confused by the article’s Rust/Go intro and initially assumed jj was a language; later clarified it’s a new VCS that can operate directly on git repos.
  • jj is its own DVCS with pluggable backends (git in open source, Piper internally at Google) but can be treated as “a different UI on top of git repos” for most users.

Perceived advantages over Git

  • Simpler conceptual model: fewer features, more coherent composition; working copy is always a commit, stashes and index are replaced by regular commits and rebases.
  • Safer experimentation: jj undo/redo operates over an operation log, giving a universal “back button.”
  • Rebasing and stacked work: change IDs survive rebases, making long chains of dependent branches and stacked PRs easier to maintain; cascading rebases happen automatically.
  • First-class conflicts: merges/rebases never “fail,” they record conflicts to resolve later, reducing forced context switches.
  • Megamerge/”stack” workflows: easy to test multiple feature branches together and then push changes back down into individual branches.

Pain points, missing features, and skepticism

  • Some find jj more complex for simple “single main branch” workflows, especially around bookmark management and push/pull ergonomics.
  • Git email workflows (format-patch/am) and rebase -x-style linter hooks aren’t fully replicated; jj fix is more limited.
  • Hunk selection and partial commit UX is seen as worse than tools like magit or Sublime Merge; some users fall back to git GUIs on jj repos.
  • Skeptics argue git is “good enough,” learning a new VCS has opportunity cost, and jj may just add ecosystem fragmentation. A few feel the hype is overblown or “astroturfed.”

Tooling, GUIs, and LLMs

  • Adoption blockers mentioned: lack of polished VS Code / magit-equivalent UIs and uneven editor integration.
  • jj awareness in LLMs is low; early users see hallucinated commands. Debate over whether “LLM knowledge” should matter for tool adoption.

Forges and organizational context

  • A new “jjhub-like” service (ERSC) aims to provide stacked-diff/commit-stack oriented hosting and review, beyond what GitHub offers today.
  • jj is already used significantly at Google and compared to Sapling at Meta; some note Google’s history of churning internal VCS tooling.

Broader VCS landscape

  • Pijul, Fossil, Perforce, Mercurial, and Sapling are discussed as alternatives with different tradeoffs (patch theory, integrated web UI, binary support).
  • Many see git compatibility as essential for any realistic challenger; colocating with git is cited as jj’s key practical advantage.