jj init – getting serious about replacing Git with Jujutsu

Original Article ↗ Hacker News Discussion ↗

A new version-control tool called Jujutsu (“jj”) aims to replace Git’s user-facing workflow while remaining compatible with existing Git repositories. Commenters are intrigued by jj’s model where the working copy is always a commit, its simplified handling of history editing and stacked changes, and potential advantages for large or complex workflows—but many are skeptical about losing Git’s index, worry about added conceptual complexity, and question whether developers should instead just learn Git’s underlying model. Overall, people see promise in jj for improving ergonomics and tooling, yet doubt it can overcome Git’s dominance or fully escape Git’s underlying complexity.

Overall reception of Jujutsu (jj)

  • Several commenters are intrigued by jj and plan to try it, especially those already frustrated with Git’s UI.
  • A few people who have switched report initial friction, mainly due to the “working copy is a commit” model, but say that once it “clicks,” Git then feels clunky.
  • Others are skeptical, viewing jj as adding complexity on top of Git rather than truly simplifying version control.

Working copy as a commit & lack of index

  • jj’s model: all changes are always part of a commit; there is no exposed “index” or unstaged state.
  • Supporters argue this reduces conceptual states and makes operations like splitting commits easier and less error‑prone.
  • Critics prefer Git’s two‑step “add then commit,” saying it encourages deliberately grouping related changes and avoids auto‑committing everything.
  • There’s some confusion about whether jj meaningfully preserves index-like behavior; one commenter clarifies that it effectively commits all changes by default.

Commit splitting and workflows

  • jj’s split command is heavily discussed.
  • Fans say it dramatically lowers friction for retroactively splitting commits and reorganizing history compared to Git’s multi-step rebases.
  • Detractors find jj split’s workflow unintuitive (e.g., which part is considered “first” vs “second”), and argue that splitting is too important to get “weird.”

Git complexity, mental models, and learning burden

  • Many comments lament Git’s confusing concepts (detached HEAD, reflog, rebase merge semantics, ours/theirs inversion), and the frequency of “footguns.”
  • Others defend Git as powerful but not excessively hard if you internalize its core model; they argue developers should learn tools more deeply, likening this to understanding databases or networking.
  • There is disagreement over whether “needing to understand internals” is reasonable for everyday use.

Tooling, GUIs, and large repos

  • Multiple people emphasize the importance of good GUIs (for staging, hunk selection, bisect, reflog) and say next‑gen VCS should be GUI‑first.
  • Some note jj currently lacks mature GUI support, which weakens workflows that rely heavily on the index-like staging experience.
  • For large repos, watchman is mentioned as a way to improve jj’s performance, but overall large-repo behavior remains lightly discussed and somewhat unclear.

Meta points: naming, ecosystem, and longevity

  • Concerns appear about the binary name jj conflicting with common Vim keybindings.
  • Some worry about jj’s longevity due to association with Google-funded work, while others clarify it is not a Git fork and simply uses libgit.
  • A few suggest that what’s most needed is not a new VCS but a saner Git-compatible interface or frontend.