From: Petr Baudis Date: Sat, 12 Nov 2005 21:03:06 GMT Subject: Re: git-merge-recursive: documentation and implementation notes 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 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? -- 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.