Re: [PATCH v5 0/3] Teach git-replay(1) to linearize merge commits

From: Toon Claes <toon@iotcl.com>
Date: Jun 30, 2026, 13:42 UTC
Message-ID: <87a4sc400s.fsf@emacs.iotcl.com>
In-Reply-To: <f8b520d1-edeb-9e45-c503-025c8b5833c3@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> So I fear that the `replayed_base` design _is_ needed, and the only way
> `git replay --linearize` can work with multiple branches is by linearizing
> all of the replayed commits into one single, linear commit topology.

Well, I'm getting the feeling you're right here. But then this change is no longer related to merge commits only. Replaying multiple branches with --onto and --linearize would always replay them into a single line hiearchy?

Personally, I would be totally fine with that. We need to lay that out very clearly in the docs, but that is in my humble opinion also a strong argument to name it `--linearize` and not `--replay-merge=linearize` or whatever we've been discussing.

Show 5 quoted lines

> Obviously, there are ways one could _try_ to rescue the previous idea, so
> that at least replaying just branches A and B would keep the replayed
> commits non-reachable from each other, but I strongly suspect that any
> such design will invariably surprise users in nasty ways when the logic
> has to fall back to the simple idea I outlined anyway.

I don't like the "try" in there. I think it's better to have predictable behavior. Users always have the choice to replay branches in separate git-replay(1) calls, although that comes with a downside that commits shared by those branches will be replayed separately and will get duplicated, unless they fiddle with the COMMITTER_DATE.

-- 
Cheers,
Toon