Jujutsu megamerges for fun and profit

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.