Jujutsu worktrees are convenient (2024)

Perceptions of Git: Power vs Pain

• Some view Git as one of the best pieces of software: battle-tested, efficient, and vastly better than CVS/SVN/Hg in practice.
• Others argue the opposite: Git’s UI is called “the worst software ever written,” with claims it has wasted huge amounts of developer time.
• Terminology inconsistency (“index”/“cache”/“staging” and flags like --staged) is cited as evidence of poor UX and user-hostile design.
• Defenders note that some confusing terms arose historically or from third parties, but critics counter that Git never cleaned this up properly.
• There’s broad agreement that the underlying data model is strong, but the CLI is complex and mentally “bulky.”

What Jujutsu (jj) Actually Is

• Multiple comments correct the misconception that jj is “just a Git frontend.”
• jj is its own VCS with its own model and algorithms, which can use Git’s on-disk format as a backend and optionally “colocate” with .git.
• Key jj advantages mentioned:
  • Operation log that makes undoing/replaying commands trivial compared to digging through reflog.
  • Easier history editing: stacked PRs, rewriting earlier commits while propagating changes, decomposing/cleaning large PRs.
  • A workflow that separates “machine history” from “human-curated history.”
• Some users love jj and use it as their main client; others tried it and found existing Git tooling (e.g., git-spice, magit) sufficient or more familiar.

Worktrees vs jj Workspaces

• Git worktrees and jj workspaces solve similar problems: working on multiple branches/tasks in parallel without constantly stashing/committing.
• Benefits highlighted:
  • Kick off long CI/build/test runs in one tree while continuing other work in another.
  • Preserve editor/build caches, terminal history, and per-branch environment setup.
  • Increasingly used for running multiple AI agents or Claude Code instances in parallel, often mapping each ticket/issue to a worktree.
• Limitations and differences:
  • Git allows only one worktree per branch; jj workspaces do not have this restriction and are considered “nicer” for keeping a clean main.
  • Some find worktrees unnecessary overhead vs simply cloning with shared storage and local remotes.
  • jj workspaces currently may lack .git in the workspace directory, breaking some Git-based editor tooling and company scripts; fixes are said to be in progress.
  • Git LFS support in jj is not ready yet (basic support is under development).

Workflow and Philosophy

• Advocates say jj “bakes in” many Git best practices (e.g., disciplined, atomic commits; easy fixups; stacked branches) that in Git require extra tools or rituals.
• Skeptics ask how jj materially improves common workflows like “CI failed, fix branch A while working on branch B,” since Git worktrees already handle this.
• Several comments stress that Git and jj can both be good: jj mainly offers a different mental model and nicer affordances, not a fundamentally new capability set.