Re: Converting merge to rebase in the presence of conflicts

[Michael Haggerty <mhagger@alum.mit.edu>]

On 04/11/2011 05:15 PM, Hrvoje Nikšić wrote:
> [...]
> I still wonder why rerere is necessary here. After all, even without
> the rerere metadata, the information about conflict resolution is
> right there, in the merge commit, and rebase could conceivably make
> use of it. What am I missing?

In general, merge and rebase are quite different animals.  In the
example you provided, there was only one conflicting commit being
rebased, so the difference is not so apparent.

One commit merged:

*--*--a--m      "master"
    \   /
     b--

One commit rebased:

*--*--a                           *--*--a--b'        "master"
    \              ->
     b

In either case, "git diff a..master" is identical.  Therefore,
converting "one commit merged" into "one commit rebased" simply involves
forgetting the second parent of commit "m".  The "rerere" facility will
indeed help you here, as other people have suggested.

But if more than one commit is being brought in from the branch, then
merge and rebase are more distinct.  Merge forces you to resolve the
conflicts only once, in a single merge commit, whereas rebase forces you
to resolve the conflicts one commit at a time.

Multiple commits merged:

*--*--a---M      "master"
    \    /
     b--c

Multiple commits rebased:

*--*--a                          *--*--a--b'--c'     "master"
    \              ->
     b--c

It should still be that "git diff a..master" gives identical results in
the two cases, but there is still a big difference--in the rebase
example, master after commit "b'" should be a functional state that can
be compiled and passes the unit tests.  The state at commit "b'"
includes a combination of the changes made in "a" plus the changes made
in the original "b".  In the merge example, there is no state of the
tree that is equivalent; there is only a+b+c.  This lack of intermediate
conflict resolution is what makes merges problematic for "git bisect".

Now, you want a way to transform the merge into a rebase automatically.
 In other words, given the information in the "multiple commits merged"
example as raw material, how can you convert it into a rebase?  This is
only possible if you are willing to squash "b", "c", and "M" into a
single commit:

*--*--a--bcM

because you have only told git how to resolve the conflicts between "a"
and "b+c", not between "a" and "b" without "c".

This is why I have advocated "rebase with history" [1], which retains
both the intermediate conflict resolutions and also the merge information:

*--*--a--b'--c'     "master"
    \   /   /
     --b---c

Michael

[1]
http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/