Re: [PATCH v7 3/3] replay: offer an option to linearize the commit topology

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 13, 2026, 22:09 UTC
Message-ID: <xmqqbjcawnhp.fsf@gitster.g>
In-Reply-To: <CABPp-BGzU9KHGF1nipi2HZaa1AiikMKGGaapQzHVH06wO4V1ww@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 16 quoted lines

> For what it's worth, looking back at the v5 thread, it seems the `base
> = last_commit` rule came in to fix the real bug Junio and Phillip
> pointed out there -- that without it, only one side of a linearized
> merge survived.  That fix is clearly correct for the single-branch
> case.  My worry is only that applying it unconditionally reintroduces
> the multiple-positive-refs ordering problem we deliberately avoid
> elsewhere.  Making `--linearize` reject multiple positive refs would
> keep the merge-flattening fix while sidestepping this entirely.
>
>> A user
>> who wants to linearize ranges independently is advised to use separate
>> git-replay(1) invocations.
>
> Which, to me, is another argument for just disallowing multiple
> positive refs under `--linearize`: if the recommended way to do it is
> separate invocations anyway, we may as well require them.

Hmph. To me, this is slightly different. It acts more like an escape hatch: "if you really do not want to mix unrelated things into a single linear history, you can do this other thing."

Stepping back, the unpredictable order of multiple merged lines of history exists even without multiple positive refs. If you have independent lines of development that were merged and you linearize them, someone must choose which line comes first. If you let the machinery make that decision, the resulting commit order may not reflect your preferences.

While I rarely perform octopus merges anymore, in situations where an octopus merge is appropriate (e.g., when you have N independent branches and their merge order does not matter), linearizing such a history into a random sequence of N segments, built on top of one another in an unspecified order, could actually be considered a feature. You do not have to make a decision about something that is inconsequential.

So, I am not convinced we should forbid this behavior to avoid dealing with a history containing merges or multiple positive tips.

When achieving a strictly linear history is the user's goal under the "--linearize" option, is it not inherent that there is no single "correct" order for these independent segments of history to appear in the final linear result?

Perhaps I am not reading you correctly, but that is how I read that escape hatch explanation.

Thanks.