"Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes: > 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... A merge does not look at the history. It _does_ look at the history to figure out what the common ancestors are, but after finding them out, the "file history" is not examined by following each step in the ancestry chain (that would have been the "blame merge"). >> 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. Exactly. We may keep conflict markers in the file left in the work tree to highlight which lines are unique to the side that added more (iow, one group of lines delimited by <<< === >>> is empty while the other is not) but this is currently treated as "fishy, needs human validation" to catch mismerges. - 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
