Jujutsu at Google [video]

Original Article ↗ Hacker News Discussion ↗

Video & conference context

  • Talk is part of a larger JJ Con playlist; some find it odd the YouTube video is unlisted, seeing it as typical Google underexposure.
  • A separate JJ-Con wiki page aggregates talks, slides, and notes.
  • Multiple people complain about the poor audio quality and “point a camera at the lectern” conference style.

Google internal rollout & dev environment

  • “GA in 2026” refers to Google-internal general availability on Linux only; external jj is already usable on multiple platforms.
  • Google is predominantly Linux for dev, with an in-house Debian-based distro (gLinux) and internal mirrors; Macs and some Windows machines are used as terminals into remote Linux boxes.
  • Many devs use macOS locally but build and run on Linux in the datacenter, reducing urgency for native jj on macOS except for iOS/macOS devs.

Jujutsu vs Git: why and for whom

  • Fans describe jj as simpler yet more powerful than git: easier CLI, automatic rebasing of dependent commits, an explicit “undo” for repo operations, no staging area, and strong support for stacked/atomic commits.
  • Git experts note that many workflows are possible in git but feel arcane, brittle, or tedious compared to jj’s first-class support (e.g., history surgery, filtering, and commit rewriting).
  • Skeptics say they rarely need more than basic git commands and haven’t experienced git as a bottleneck, especially on smaller repos.

Conflicts, stacks, and workflows

  • First-class “conflicted commit” state is a major selling point: you can defer conflict resolution, keep working elsewhere, and later fix conflicts without being stuck in a modal rebase.
  • JJ auto-rebases children when you amend a commit, making long stacks of dependent changes and “PR stacks” much easier to maintain.
  • Auto-snapshotting on every command and treating all changes as commits makes context switching and splitting commits easier, similar in spirit to IDE “local history.”

Git usability debate

  • Strong divide: some insist git is straightforward if you internalize the commit-graph model and read the docs; others say the documentation is implementation-heavy (trees/blobs) and intimidating.
  • Many report that errors and “weird states” (especially around rebase, detached HEADs, and collaborative mistakes) are where git becomes scary and time-consuming, even for experienced users.
  • Reflog is cited as a safety net, but proponents argue jj’s global operation log (oplog) is a more comprehensive and user-friendly history of changes.

Scale and monorepos

  • Several comments stress that opinions formed on “hundreds of devs, hundreds of MB” repos don’t generalize to multi-terabyte monorepos.
  • Google’s internal systems (Piper, earlier git-like frontends such as “git5”) struggled with monorepo scale and workflows; jj is seen as a modern alternative frontend that still uses git as backend externally.

Compatibility & ecosystem concerns

  • JJ lacks full support for some git ecosystem features: LFS, hooks, submodules, and creating tags via jj itself (though git can be used alongside).
  • Some argue this limits jj as a drop-in git replacement for organizations with complex CI/integration setups and existing submodules/LFS usage.
  • CLAs are required and contributions currently need a Google account; this is perceived by some as a barrier despite the project being independent of Google.

Collaboration & “serverless” setups

  • One appeal of jj is safer use with shared folders (Dropbox, Google Drive, USB) due to its concurrency design; git repos in such environments are historically fragile.
  • Others counter that bare git repos on shared drives plus SSH are simple and sufficient, and see Dropbox issues as a storage problem, not a git problem.

Presentation style discussion

  • Large subthread critiques the slide deck and delivery: too much text per slide, tendency for viewers to read ahead, and difficulty syncing spoken words with bullets.
  • Many advocate “less text, more structure”: fewer bullets, clearer narrative (situation–consequence–action–result), and emphasizing key impacts rather than deep internals for a general audience.
  • There is disagreement on “passion”: some want more energy and motivation in technical talks; others prefer dry, information-dense delivery and resent TED-style exhortations.
  • Several commenters praise the presenter’s openness to feedback and note the talk may have been well-calibrated for the in-person audience (experienced jj users) but less so for random YouTube viewers.