Re: git merge no longer handles add/add

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Nov 20, 2007 at 07:33:27AM +1300, Martin Langhoff wrote:
> On Nov 19, 2007 7:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > 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...
> 
> > 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.

That sounds like an inevitable consequence of git's design--it only uses
a global (not a per-file) common ancestor.

--b.