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

From: Fredrik Kuivinen <freku045@student.liu.se>
Date: Nov 13, 2005, 17:12 UTC
Message-ID: <20051113171207.GB4805@c165.ib.student.liu.se>
In-Reply-To: <20051112210306.GG30496@pasky.or.cz>

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

Show 21 quoted lines

>   Hi,
> 
> Dear diary, on Sat, Nov 12, 2005 at 09:34:57PM CET, I got a letter
> where Fredrik Kuivinen <freku045@student.liu.se> said that...
> > 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

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