Re: question about a merge result

[Francis Moreau <francis.moro@gmail.com>]

On Thu, Apr 30, 2009 at 4:26 PM, Jeff King <peff@peff.net> 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