Junio C Hamano <[email protected]> writes:
> 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.
And just after I send the message because I needed to catch a bus, I
notice that there is a problem.
Actually, "replay diff going from B to Z instead of merging" must be
done very carefully. Imagine when Y in the original history were a
cherry-pick of M. What you would be creating would look more like
this instead:
O X'--.
\ / \
M---N---A'--B'--Z'--
because Y' becomes a no-op, as the transplanted history already has
M applied. But the original "diff going from B to Z" has the effect
of M already in there. You would end up adding the same hunk twice
without noticing. You somehow need to come up with a way to deal
with this.
If you did a real merge between X' and B' to recreate Z', you would
not have such a problem.
One way to be careful when recreating Z' out of Z might be:
- Retry a merge between the original B and Y, with conflict
markers intact;
- Compare the result with what is recorded in Z. The
differences are textual conflict resolution and evil merge
changes;
- Now try a merge between B' and Y', with conflict markers
intact;
- Apply the difference you obtained in the second step to the
result of the third step.
which is essentially the same as what rerere does.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
