From: Francis Moreau Date: Thu, 30 Apr 2009 15:05:19 GMT Subject: Re: question about a merge result Message-ID: <38b2ab8a0904300805j5ce19617mdda3254c37d06d38@mail.gmail.com> In-Reply-To: <20090430142635.GB23550@coredump.intra.peff.net> On Thu, Apr 30, 2009 at 4:26 PM, Jeff King wrote: > On Thu, Apr 30, 2009 at 02:34:43PM +0200, Michael Gaber wrote: > >> > So merging 'b1' into master removed the B file even if in branch 'b1' >> > I restored it. >> > >> > Could anybody explain me why this is the correct behaviour and why not >> > file 'B' is not restored as it was done in branch 'b1' ? >> >> well, I'd say the thing is, that in b1 there is no change at all to the >> tree anymore, so when applied to master (without B) there is no b restored > > That is exactly it. Git's 3-way merge doesn't look at the intervening > history at all. It looks _only_ at the two endpoints and their > merge-base (well, that is a bit of a simplification, as there may be > multiple merge-bases, but it is what is happening here). > Well, obviously it's how git works since it's what I got. But the question was more about if the cortectness of the end result: should 'B' removed after the merge. IOW if someone works on its own branch remove B file and thought it was a bad idea and restore it whereas another person remove B file but miss the fact that it was a bad idea, does the merge should silently remove B file ? -- Francis