Re: git merge no longer handles add/add

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 19, 2007, 06:43 UTC
Message-ID: <7vtznipweu.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <46a038f90711181929x4bf0794eue73a5dbac8e2688a@mail.gmail.com>

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

Show 16 quoted lines

> 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

      **************

Show 12 quoted lines

>     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.