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

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> 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.