Jujutsu VCS: Introduction and patterns

Skepticism and Adoption Barriers

• Several commenters say they won’t try Jujutsu (jj) because “git works” and they prioritize path-of-least-resistance.
• Others say blog posts and demos haven’t clearly or concisely explained why jj is better or shown a guided tutorial-style narrative.
• Some think jj doesn’t add fundamentally new capabilities vs git; it “just” makes existing workflows easier.

Perceived Advantages Over Git

• Many report jj as the biggest improvement to their workflow since adopting git itself.
• Key theme: lower cognitive load and a more coherent, consistent model; commands “match how you think”.
• Undo is universal (including rebases, splits, squashes, working copy changes) via an operation log.
• Commit history cleanup and stacked PRs become routine rather than painful chores.

Workflows and Patterns

• Editing old commits and automatically rebasing descendants is described as trivial and central to jj’s appeal.
• Stacked PRs and “working on two things at the same time” are highlighted as much smoother than in git, especially with auto-rebase.
• Two main usage styles emerge:
  • “Edit workflow”: directly edit commits in the graph.
  • “Squash workflow”: keep an always-dirty @ change, then squash or split into earlier commits.
• Commit messages can be written before coding, used like a todo queue processed with jj next.

Conflicts, Mutability, and Safety

• Conflicts are first-class: attached to commits, not to an in-progress rebase. They can be deferred, resolved in any order, and automatically propagated.
• jj distinguishes mutable vs immutable commits (e.g., main and some remote history). Commands that would rewrite immutable history are blocked unless explicitly overridden.
• jj git push behaves like git push --force-with-lease by default, and immutability can be tuned to local policy.

Integration and Tooling

• jj usually runs against a git backend and is invisible to collaborators using plain git.
• It can also back onto other backends (e.g., monorepo systems), which some see as strategically important.
• Reported gaps: no git hooks yet; weaker IDE/UI integration (though workarounds, gg GUI, TOML schema, and better docs are emerging); past HTTPS/credential and fetch performance issues now partly addressed.

Critiques and Open Questions

• Some argue the real unsolved VCS issue is having separate representations for “changelog for humans” vs “precise chronological record for debugging”; jj is seen as an incremental improvement, not a solution to that deeper split.
• A few users report confusion around status behavior and documentation, suggesting ergonomics still need polish.