Hi, On Thu, 30 Jul 2009, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > The codepath saw that one branch renamed dev-ubuntu/ stuff to dev/ at > > that "unmerged" path, while the other branch added something else to > > the same path, and decided to add that at an alternative path, and the > > intent of that is so that it can safely resolve the "renamed" side to > > its final destination. The added update_file() call is about > > finishing that conflict resolution the code forgets to do. > > By the way, (I am CC'ing Fredrik, the author of the merge-recursive.py, > the original implementation, even though I haven't seen him around here > for a long time. Two "thieves" are also CC'ed), I think the way recursive > strategy tries to handle rename/add and rename/rename conflicts by coming > up with a temporary pathname is fundamentally wrong. > > If our branch (stage #2) added by renaming and their branch (stage #3) > added by creating the same path, why can't we simply leave these two > stages in unmerged state without funny "unique_path()" renaming? AFAIR we could not leave the two in unmerged state because the "recursive" part of the recursive merge demands that we be able (at the intermediate merges) to write a tree. But I agree that coming up with unique paths is wrong: if it is a rename/rename conflict, it should be <<<<<<< ======= <file1> >>>>>>> for one and <<<<<<< <file2> ======= >>>>>>> for the other rename target. Ciao, Dscho -- 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