Megamerge: how to bring updates from remote branches without remerging.

[redbaron]

After reading about megamerge flows in few places, I gave jj a go and generally happy with it. One question still bugs me though.

1. I start with megamerge jj new A B C D. This results in a painful conflicts, which I have no option, but to resolve them.
2. bringing my own changes in either parent is simple with jj squash -A

but I have trouble bringing remotes updates from either parents. Currently I do just jj new @ A' to bring updates from remote A and continue working, but overtime it creates ugly merge tree, which are hard to read. If I do jj new A' B C D again, I'll need to resolve conflicts, even if A' update itself didn't introduce any new ones.

Example tree after megamerge of 4 branches and then one follow up merge of the update:

@    xorlyxwz xxx@yyy 2026-05-23 11:17:43 tofu@ ff58687c
├─╮  (empty) (no description set)
○ │        mwomvzko xxx@yyy 2026-05-23 11:17:43 9c7ae5eb
├───┬─┬─╮  (no description set)
│ │ ○ │ │  uopmpkrx xxx@yyy 2026-05-22 14:55:20 bookmark1 a0745a7e
│ │ │ │ │  msg1

I tried to jj squash -t mwomvzko , but it done nothing to the merge structure. I also tried to jj abandon mwomvzko , which does simplify merge tree, but it forces me to re-resolve all conflicts.

[jennings]

Rebase the megamerge commit.

jj rebase -s mwomvzko -o 'mwomvzko- ~ A' -o A1

This rebases mwomvzko and all its descendants onto its current parents except A, plus A1.

The merge conflict resolutions are still inside change mwomvzko so you won't have to reapply them.

If you find this simpler, you could add in an additional parent then use jj simplify-parents to remove the redundant parent:

jj rebase -s mwomvzko -o 'mwomvzko- | A1'
jj simplify-parents

[redbaron]

This is really nice. So the idea is to preserve change with conflict resolution and reuse it by moving to new parents. simplify-parents doesn't work well for me, because if master branch was one of parents and another branch was based on the latest master, then it drops master from a list of parents.

I don't suppose it is possible to find new heads to rebase onto after jj git fetch? jj doesn't record bookmarks which went into megamerge, so when they are moved by git fetch it doesn't know which to use.

I tried to come up with something , like (@--:: ~ @-::) & (bookmarks() | remote_bookmarks()), to find all updates to parents, but then if one parent was master it will start taking in new branches.

[jennings]

I don't have a direct answer for you, right now I think it's something you'd need to script by inspecting the op log to get the previous position of master.

In my workflow, I never bother keeping main as a direct parent of the megamerge. Instead, I rebase the individual branches onto main (which can be done all at once with jj rebase -o main -b <merge_commit>

[redbaron]

I rebase the individual branches

Not everything what goes into megamerge are my branches. But you gave me an idea, maybe I should always add -o 'trunk()' to my rebase and then simplify-parents: this will ensure that trunk is always in even if indirectly. I don't need to have trunk as direct parent then, because I know it is special cased like that.

[redbaron]

Got this working:

'closest_merge' = 'closest_merge(@)'
'closest_merge(to)' = 'heads(::to & merges())'
'mm_updates'= '(closest_merge-:: ~ closest_merge:: & (bookmarks()|remote_bookmarks())) | trunk()'

then :

jj rebase -s closest_merge -o mm_updates
jj simplify-parents

allows me to bring any new updates since megamerge creation. As a bonus it will also bring rebases (and force-pushed) branches from others. As a downside it will also bring new unrelated branches pushed to remote since last update, so occasionally I'd need to rebase megamerge to a narrower set of parents manually. Another downside is that I need not to forget to advance local bookmarks after squashing work into one the parents.

[redbaron]

Found this: #8484 (comment) which aims at the same goal, but works differently it seems (still didn't figure out how).

[redbaron]

All of it (and more) is explained in https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-and-profit