Jujutsu megamerges for fun and profit (13 minute read)

Jujutsu's megamerge workflow lets developers work on top of all their branches simultaneously by creating octopus merge commits with many parents, eliminating context switching friction.

What: A detailed guide to using "megamerges" in Jujutsu, a version control system where you create a single merge commit that combines all your active feature branches, bug fixes, and work-in-progress changes as parents, then work on top of this combined view instead of switching between individual branches.

Why it matters: This workflow catches integration issues immediately since you're always working with all changes combined, eliminates surprise merge conflicts when submitting PRs, and makes it trivial to jump between tasks or create small drive-by fix PRs without VCS gymnastics.

Takeaway: Try Jujutsu with the provided config aliases for stack, stage, and restack commands to experiment with the megamerge workflow on a non-critical project.

Deep dive

Merge commits in version control are just regular commits with multiple parents, not special entities, and can have three or more parents (octopus merges)
The megamerge workflow involves creating one octopus merge commit as a child of every branch you're working on, then doing all work on top of this combined state
Key benefits include always compiling/testing against the full combination of your work, discovering merge conflicts immediately, and switching tasks by just editing different files without VCS commands
The megamerge itself never gets pushed to remote repositories, only the individual branches that compose it get published as separate PRs
Creating a megamerge is simple: jj new x y z followed by jj commit --message "megamerge" creates the base, with work happening in commits above
Getting WIP changes into proper branches uses jj absorb (automatically identifies which downstream commit each change belongs to) or jj squash --interactive for manual control
Custom aliases like stack and stage automate inserting new branches into the megamerge structure using revset queries
The restack alias solves the challenge of rebasing only your mutable commits onto trunk while leaving other contributors' branches untouched
The workflow relies heavily on Jujutsu's first-class conflict support and powerful revset language for targeting specific commits
Revset functions like closest_merge(to) find the nearest merge commit ancestor, while roots(trunk()..) & mutable() identifies rebaseable commits
The --simplify-parents flag cleans up redundant edges in the commit graph after complex rebase operations
Practical usage involves absorb/squash for modifying existing commits, rebase for new commits, and stage/stack for moving entire branches into the megamerge

Decoder

Jujutsu (jj): A Git-compatible version control system with better support for workflows like handling conflicts as first-class objects and powerful commit manipulation
Octopus merge: A merge commit with three or more parents, combining multiple branches simultaneously rather than the typical two-parent merge
Megamerge: An octopus merge commit that combines all of a developer's active branches, serving as the base for all work
Revset: Jujutsu's query language for selecting sets of commits using predicates and set operations
absorb: A command that automatically identifies which downstream commits your current changes belong to and squashes them appropriately
trunk(): A revset alias typically referring to the main development branch (like main or master in Git)
Mutable/immutable commits: Jujutsu's concept of which commits you're allowed to modify, protecting published or shared work from accidental rewrites

Original article

Jujutsu megamerges let developers work on many different streams of work simultaneously. This article provides an in-depth explanation of how they work. Megamerges are a way of showing developers the whole picture and are not really meant to be pushed to remote. Developers will still want to publish branches individually as usual.