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

From: Petr Baudis <pasky@suse.cz>
Date: Nov 12, 2005, 21:03 UTC
Message-ID: <20051112210306.GG30496@pasky.or.cz>
In-Reply-To: <20051112203457.GA5234@c165.ib.student.liu.se>

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...

Show 12 quoted lines

> 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?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.