Re: [PATCH/RFC] rebase -p: do not redo the merge, but cherry-pick first-parent changes

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

Johannes Sixt <j6t@kdbg.org> writes:

> Today I was able to use rebase -i -p in the field. I used it to rebuild
> an integration branch (akin to git's pu branch). Guess what? It did not
> work as expected:
>
> Two of the topic branches' early parts were already merged in the
> upstream. The instruction sheet had only 'pick' of merge commits for the
> topics. Except for these two; there, all commits (that were not yet in
> upstream) were offered to pick, including the merge commit.
>
> I started with this:
>
>     A--M--o--o   <- master
>    /  /
> --o--X--Y        <- side branch (partially merged in master)
>    \     \
>     R--S--N--T   <- integration (to be rebuilt on master)
>
> I wanted this:
>
>      A--M--o--o
>     /  /       \
>    /  /          R'--S'--N'--T'
> --o--X--Y---------------´

It is unclear what exact revisions you gave to rebase, but I am assuming
that you asked "rebase --onto master X^ T" (you can use R^ instead of X^;
they refer to the same commit).

It is straightforward to see what should happen to R and S; they should be
a straight replay of single parent commit on top of 'master'.  

But it is unclear what should happen to X and Y.

When you are rebasing the X^..T sub-DAG, can you say what makes S more
special than Y by looking at the original topology?  Your "I wanted this"
picture depicts S' to be rewritten but Y stays the same.  Why?  

They are both in the X^..T DAG, and neither of them is merged to 'master'.
I can sort of see why X and R would be treated differently (X is part of
master, R is not), but I cannot justify why your "I wanted this" picture
replays S' without replaying Y'.

What am I missing?

> But I got this:
>
>     A--M--o--o-------Y'
>    /  /       \       \
> --o--X--Y      R'--S'--N'--T'

Which is what I would expect, from the "Y and S play a similar role in the
sub-DAG X^..T in the original DAG, with respect to master" point of view.