"Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes:
> On Nov 19, 2007 4:18 PM, Martin Langhoff <martin.langhoff@xxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
