Johannes Schindelin [off-list ref] 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.

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