Sergey Organov <sorganov@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html