Re: git merge no longer handles add/add

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Nov 19, 2007, 18:33 UTC
Message-ID: <46a038f90711191033s4bc5ab50kd3e4f30d6b301e43@mail.gmail.com>
In-Reply-To: <7vtznipweu.fsf@gitster.siamese.dyndns.org>

On Nov 19, 2007 7:43 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

> As far as the point of the merge is concerned, that's an add/add
> of _different_ contents, and we have always left the conflict to
> resolve for you since day one.  The only case we handle without
> complaining is the accidental *clean* merge.  Both branches adds
> the path *identically* compared to the common ancestor.

Even if the 2 paths did have matching content at one point? In fact, the 2 files here get added with identicaly content and one of them is later modified...

Show 6 quoted lines

> The very initial implementation of merge may have used the total
> emptyness as the common ancestor for the merge, and later we
> made it a bit more pleasant to resolve by computing the common
> part of the file from the two branches to be used as a fake
> ancestor contents.  But the fact we left the result as conflict
> for you to validate hasn't changed and will not change.

In this case, if you use the common part (100%) as the ancestor, then you get a _clean_ merge. The file is added on both sides identically, and then it changes on one side.

I'll see if I can repro with an older git install...