Re: git merge no longer handles add/add

[Junio C Hamano <gitster@pobox.com>]

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

> On Nov 19, 2007 4:18 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>> Happens with recursive and resolve. Happy to provide a minimal repro
>> case, but I think this is fairly obvious...
>
> Steps to repro...
>
>     mkdir repro
>     cd repro/
>     cp /etc/resolv.conf ./resolv.conf
>     git init
>     git add resolv.conf
>     git commit -m 'a' resolv.conf
>     cp resolv.conf resolv-1.conf
>     git add resolv-1.conf
>     git commit -m 'a1' resolv-1.conf
>     echo blabla >> resolv-1.conf
      **************
>     git commit -m 'a2' resolv-1.conf
>     git-branch other HEAD^^
>     git checkout other
>     cp resolv.conf resolv-1.conf
>     git add resolv-1.conf
>     git commit -m 'b'
>     git checkout master
>     git merge other
>     ...
>    Auto-merged resolv-1.conf
>    CONFLICT (add/add): Merge conflict in resolv-1.conf
>    Automatic merge failed; fix conflicts and then commit the result.

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.

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.