Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Sergey Organov [off-list ref] writes:

1. How to calculate the set of commits to rebase.

2. How to rebase merge commits.

Can we leave (1) for a while at its current state and focus on (2)?

Perhaps.  You would have to be careful though, so let me think aloud
a bit...

Suppose you started from an upstream history whose tip was B, and
you worked on merging some changes X an Y you made earlier on a side
branch.

         X---Y
        /     \
   O---A---B---Z---

In the meantime, the upstream history has advance and now it looks
like this:

   O---A---B---C---D

You want to forward-port the change done by X, Y on the side branch
and its merge Z on top of D, right?

In other words, you want to have this:

         X-----------Y
        /             \
   O---A---B---C---D---Z'

In this case, replaying the difference going from B to Z on top of D
may be better than redoing a merge between Y and D, in that the
former will carry evil merges and resolution of conflict forward.

I wonder if it will be the right way to get a correct result to
apply the difference to go from B to Z on top of an old commit when
you are side-porting.

Imagine you want to backport the same X-Y history by redoing the
merge Z on top of another child of O (i.e. A's sibling).  That is,
you start from this:


         X---Y
        /     \
   O---A---B---Z---
    \
     M---N

and would want to create this:
    
    
   O           X'--Y'
    \         /     \    
     M---N---A'--B'--Z'--

As long as everything down to the merge-base of the parents of the
original merge (in this example, merge-base across Y and B that are
Z's parents, which is A) is being transplanted, "apply the
difference going from B to Z, on top of B', to obtain Z'" should
work, I would think.