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:

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

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

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