Jujutsu megamerges for fun and profit

Original Article ↗ Hacker News Discussion ↗

Jujutsu (jj), a Git-compatible version control system, is drawing praise for workflows like “megamerges” and stacked commits that make it easier to juggle many parallel branches, refactor history, and integrate changes without the pain of stashing and complex rebases. Supporters highlight features such as the working-copy-as-commit model, powerful absorb/parallelize tools, and strong TUI/IDE integrations as major usability gains over Git, especially in large or monorepo-style codebases and AI-assisted development. Skeptics question whether these advanced workflows add unnecessary complexity or mask deeper process problems, but even some critics concede jj’s model can simplify day‑to‑day work while remaining safe via immutable-commit safeguards and Git interoperability.

Overall reception

  • Many commenters are enthusiastic about Jujutsu (jj), calling it significantly more pleasant than git, especially for complex local work.
  • Others are confused or skeptical, feeling their existing “simple feature branch + rebase” git workflow is sufficient and seeing megamerges/stacks as unnecessary complexity.

Megamerge & stacked workflows

  • Megamerges are described as disposable, local octopus merges that combine many branches (features, fixes, env tweaks, experimental work) so you always work on “the sum of everything you care about,” but only push the underlying branches.
  • Users report benefits for:
    • Large/slow CI or monorepos.
    • Features spanning multiple subsystems (e.g., backend + web + mobile).
    • Maintaining long-lived local branches (e.g., tooling/env changes) and reusing them across many feature branches.
    • Reviewing multiple PRs at once via integration branches, then pushing fixes back to the right branches using absorb.
  • Some prefer a tree-like “pairwise merge” megamerge to avoid N-way conflict resolution, citing tool limitations with >3 parents.

Git vs jj: model and ergonomics

  • Praised jj features:
    • Working-copy-as-commit, no separate staging area; rarely need stash.
    • Easy history rewriting: splitting, reordering, moving hunks between commits, empty “todo” commits.
    • absorb and parallelize for managing stacked/parallel work.
    • First-class conflicts, always-successful merges, and configurable immutability to protect shared history.
  • Git equivalents exist for some parts (git-absorb, stacking workflows with --update-refs), but are seen as clunkier.

Tooling & ecosystem

  • Multiple TUIs and VS Code integrations are recommended (jjui, visualjj, jjk, others).
  • Colocating jj with a git repo lets users keep using git-based editor features like the gutter.
  • Recent jj builds add git tag support.

Concerns & skepticism

  • Some see many parallel branches, megamerges, and stacks as signs of deeper process/culture issues rather than something to optimize.
  • Others worry about multi-parent merge conflicts, coordination with non-jj teammates, and jj’s evolving interface (pre-1.0).

AI/agent workflows debate

  • One side claims advanced LLM agents make manual VCS workflows increasingly obsolete, shifting the unit of work from branches to “intent.”
  • Others strongly disagree, citing poor agent performance on non-trivial merge conflicts and ongoing need for human oversight; some argue jj is more relevant with agent-driven, highly parallel changes.