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