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

From: Elijah Newren <newren@gmail.com>
Date: Jul 16, 2026, 03:53 UTC
Message-ID: <CABPp-BGdK8v8Qk5XB=QL_yJDPTNjSb2rN08GiPpK50V2gAj1QQ@mail.gmail.com>
In-Reply-To: <xmqqse5km6lc.fsf@gitster.g>

On Wed, Jul 15, 2026 at 11:49 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

>
> Elijah Newren <newren@gmail.com> writes:
>
> > 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.

Passing several branches isn't the user asking for concatenation; it's the user asking for replay's core feature: update many branches at once. Adding --linearize to flatten a merge does have to join the lines which that merge combined, but it shouldn't also weld together branches that were never merged in the first place. The user is combining two intended features, and the concatenation is an emergent third behavior that neither of them implies.

(Also, please note that I'm aware of the bug you raised earlier about dropped lines of history; my suggestion(s) don't reintroduce that bug.)

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

Yes, precisely! That is the problem I want to be able to solve: updating multiple branches which may have shared history. The current proposed behavior feels hostile towards that. Concretely, I want to be able to update this history:

M1  M2  M3  M4  M5
*---*---*---*---* <- main
    |   \
    |    \  A1  A2  A4  A6  A7  A8
    |     \-*---*---*---*---*---* <- branchA
    \            \     /    \
     \            *---*      -*---* <- branchC
      \           A3  A5      C1  C2
       \
        \-*---* <- branchB
          B1  B2

via `git replay --linearize --onto main branchA branchB branchC` to (depending on where A4 is ordered relative to A3 & A5):

M1  M2  M3  M4  M5
*---*---*---*---* <- main
                |
                |   A1  A2  A4  A3  A5  A7  A8
                |---*---*---*---*---*---*---* <- branchA
                |                       \
                |                        -*---* <- branchC
                |                         C1  C2
                |
                \-*---* <- branchB
                  B1  B2

(note that both branchA and branchC become linear with the merge commit A6 being dropped)

In this graph:
  * branchA and branchC cannot easily be replayed with separate
commands (it requires tracking starting and stopping points and
figuring out shared history).
  * branchB could be done with a separate command from replaying the
other two, but _only if_ the user first verifies that it has no common
history with the other branches, and I think that's not useful
cognitive load to place on the user.

If concatenation really is the intended behavior for this patch series, then --linearize seems like the wrong name for it: the surprising part isn't that each branch becomes linear, it's that the option also chains together branches that were never related.

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

No, ordered-concatenation is not something I'm interested in. I want separate branches to stay separate, as in the second graph above. I almost wish I hadn't even mentioned ordering, even though I labelled it a "minor" point in my last email, because it seems to have distracted from the real issue.

As I proposed last time, I'd be fine with erroring on multiple positive refs as an interim step (plus associated documentation and commit message updates) so this series lands, with per-branch linearization as the real fix later.