What I've learned from jj

Original Article ↗ Hacker News Discussion ↗

Jujutsu vs Fossil and Git: Philosophy and Features

  • Fossil is described as immutable-history-first: no rebasing, every mistake becomes a permanent commit; this helps data preservation but can clutter long-term history.
  • Jujutsu (jj) is change-mutable: you freely rewrite and reorder local commits, then publish only the “final” history, while jj still keeps a local rewrite history so nothing is lost.
  • Some Fossil users dislike any history rewriting as “false history”; others feel jj strikes a good balance between clean history and safety.
  • jj is “just” a CLI like git, unlike Fossil’s integrated forge/wiki/bug tracking.
  • jj removes git’s index/staging area; the working state is always tracked as part of changes, which some see as simpler and more orthogonal primitives.

User Experiences and Tooling Around jj

  • Several commenters have switched personal work to jj and report smoother workflows: easy fixups, no stashes, less index wrangling.
  • Tools like lazyjj, jjui, VisualJJ, and VS Code integrations help navigate history and provide “smartlog”-style visualization; some feel jj still needs a top-tier visual tool to match Mercurial/Sapling UIs.
  • One user found jj’s “everything tracked” behavior surprising and reverted, feeling it “messed up” their code, but others say this is by design and stable.

Pull Requests, Units of Change, and Review Workflows

  • There’s broad frustration with GitHub-style PRs as the primary “unit of change”; they often become large, messy, and hard to review.
  • Some advocate commit-centric workflows: small, self-contained commits each reviewed and signed off, often inspired by Gerrit/Perforce/Sapling-style stacks.
  • Others argue PR-centric, squash-merge workflows are simpler and safer for most teams; reviewing every commit is seen by some as excessive overhead.
  • Stacked PRs are widely liked in principle but seen as poorly supported by GitHub/GitLab; external tools like git-spice and Graphite, and jj’s change model, are mentioned as workarounds.

Commit History, bisect, and Squash Merges

  • A long subthread debates git bisect: many report it as invaluable for large, complex codebases and regressions; others say they’ve never needed it.
  • Clean, fine-grained history is framed as essential for powerful bisect and meaningful blame.
  • Squash merges are criticized for destroying that granularity, making it harder or impossible for bisect to isolate regressions.

Git’s Dominance and Appetite for Alternatives

  • Some are “tired of git alternatives” and argue people should just learn git properly.
  • Others welcome jj as a compatible, easier, and arguably superior UX atop git, and see room for dethroning git over time.
  • Missing features (notably submodules support) and ecosystem gaps (LLM tools only “knowing” git) are cited as practical blockers to fully adopting jj.