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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 15, 2026, 18:49 UTC
Message-ID: <xmqqse5km6lc.fsf@gitster.g>
In-Reply-To: <CABPp-BGxO0bd3UzDYNnhNUgDSKYwcFVCFsJ9rCzmNX7Q0xBrow@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 6 quoted lines

> You're right that when flattening merges within a single branch, the
> machinery must pick an order, and that's fine — unavoidable, even.  My
> objection isn't that; it's primarily the concatenation of distinct
> branches named on the command line into one chain, and, as a secondary
> point, the ignoring of the order of branches explicitly specified by
> the user on the command line.

That is true, but a user who wishes to avoid flattening in an unspecified order can always choose to supply only one branch at a time on the command line.

Show 5 quoted lines

> Concretely: I have three branches to rebase onto master; one of them
> happens to contain a merge I'd like flattened. I add  --linearize  for
> that one merge — and now all three branches are silently concatenated
> into a single chain.  That makes no sense to me, and I think won't to
> most users.

But if that is not the outcome they wanted, I fail to see why they would feed all three branches to a single invocation of --linearize in the first place. After all, the command is only doing what it was asked to do.

Show 25 quoted lines

> Consider the following history
>
> M1  M2  M3  M4  M5
> *---*---*---*---* <- master
>     \   \
>      \   \  A1  A2  A3  A4
>       \   \-*---*---*---* <- branchA
>        \        \
>         \        -*---* <- branchC
>          \        C1  C2
>           \
>            \-*---*---* <- branchB
>             B1  B2  B3
>
> git replay was designed to allow you to update all your branches at once.
> For example, with this above history, running
>     git replay --onto master branchA branchB branchC
> will rebase all three branches onto master (and handles the shared portion
> of history between branchA and branchC in the obvious way):
> ...
> M1  M2  M3  M4  M5  B1  B2  B3  A1  A2  C1  C2  A3  A4
> *---*---*---*---*---*---*---*---*---*---*---*---*---*
>                 ^           ^               ^       ^
>                 |           |               |       |
>               master     branchB         branchC  branchA

If that is not what you want, why did you give all three to the single invocation? If you want A's and B's all consecutive, linearlize branchA on top of 'master', and brnachB on top of it, and branch C on top, perhaps?

If that breaks because by the time you feed branchC to the machinery nobody remembers that A1 and A2 were already handled, _that_ is the problem the command needs to solve, no? I am confused.

Or do you want to be able to tell "linearlize B, A, and C in this turn on top of 'master'" and M1..M5..B1'..B3'..A1'..A4'..C1'..C2' as the result? That would mean the command line syntax cannot be an arbitrary rev list range, but limited to a single negative plus one or more positive revision, which may be very limited but is much less error prone for casual users.