Working on top of mega merges

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Dec 12, 2025, 22:00 UTC
Message-ID: <CALnO6CD8stoeUg97bq+PvRdErCoeHPg9PUMMq73RPo-8kdVt8A@mail.gmail.com>
In-Reply-To: <b3ddfaa4-526b-41e3-b12a-0fec846ac7bc@app.fastmail.com>

On Tue, Dec 9, 2025 at 1:29 PM Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:

Show 5 quoted lines

>
> On Tue, Dec 2, 2025, at 19:49, Patrick Steinhardt wrote:
> >>[snip]
>
> I haven’t used Jujutsu yet.

Same, however:

Show 6 quoted lines

> I have read or heard about the “mega merge” strategy in Jujutsu.[1]
> Being able to (this is how I imagine it could work) make a temporary
> integration branch where N branches can be edited by making edits to
> them and having all the branches be updated sounds amazing.[2][3] I have
> found myself doing temporary integration branches where I make fixes on
> top and manually cherry-picking them to the correct target afterwards.

I have done something like this once. Created a few independent branches, wrangled an octopus merge together, and then worked on top of that. When I wanted to commit, I did "commit --fixup" with the appropriate branch/commit, then eventually "rebase --autosquash --rebase-merges" or something. In that particular case, I started with empty commits on each branch, I think.

You could probably shuffle commits (like to add a new one to a sub branch) using "rebase --interactive…" there, too, but I don't think I tried that.

Anyway, the workflow did its job, but I didn't end up with something I think I'd try in practice very often, at least not yet. It did make me wonder what from jj we'd need to make things smoother, though.

-- 
D. Ben Knoble