Re: git-merge-recursive: documentation and implementation notes

On Sat, Nov 12, 2005 at 10:03:06PM +0100, Petr Baudis wrote:

  Hi,

Dear diary, on Sat, Nov 12, 2005 at 09:34:57PM CET, I got a letter
where Fredrik Kuivinen [off-list ref] said that...

quoted

Lets assume there is a merge conflict when we merge B and C in the
criss-cross case above. Then both D and E must resolve this
conflict. If they have done it in the same way we wont get a merge
conflict at M, if they have resolved it differently we will get a
merge conflict. In the first case there is no merge conflict at M, in
the second case the user has to pick which one of the two different
resolutions she wants.

Note that the algorithm will happily write non-clean merge results to
the object database during the "merge common ancestors" stage. Hence,
when we are merging B and C "internally" we will _not_ ask the user to
resolve any eventual merge conflicts.

  I find this part somewhat unclear. So how does the user pick which of
the two different resolution she wants if we will not ask the user to
resolve any conflicts?

If we have a conflict when we merge B and C we will get a file with
conflict markers from merge(1) in it, so it will look something like

    1
    2
    3
    <<<<<<
    4
    5
    ======
    6
    7
    >>>>>>
    8
    9

This file will be stored in the object database and the temporary tree
which is created by the merge of B and C will refer to it.

The algorithm will then merge D and E and use the file above as the
common ancestor. There are now two cases to consider, the first one is
that both D and E resolve the conflict above in the same way (and
possible make other changes which can be cleanly merged), we end up
with something like

    1
    2
    3
    4
    5
    8
    9

in both D and E. This will be merged cleanly into M. The other case is
that D and E either resolves the conflict differently or that they do
other modifications which aren't possible to merge automatically. In
this case we will let the user do the conflict resolution.

So, what I meant was that during the first merge, of B and C, the user
do not have to do anything with any eventual conflicts. However, in
the top-level merge, conflict resolution works in the same way as it
does for the 'resolve' strategy, i.e., the output of merge(1) is
stored in the working directory and the index is updated to make 'git
diff' useful.

- Fredrik