Elijah Newren <newren@xxxxxxxxx> writes: > When renaming one file to two files, we really should be doing a content > merge. Also, in the recursive case, undoing the renames and recording the > merged file in the index with the source of the rename (while deleting > both destinations) allows the renames to be re-detected in the > non-recursive merge and will result in fewer spurious conflicts. In other words,... > + * FIXME: For rename/add-source conflicts (if we could detect > + * such), this is wrong. We should instead find a unique > + * pathname and then either rename the add-source file to that > + * unique path, or use that unique path instead of src here. > */ > + update_file(o, 0, mfi.sha, mfi.mode, src); > + remove_file_from_cache(ren1_dst); > + remove_file_from_cache(ren2_dst); ... the use of "src" here is taking a "middle ground" and punting on resolving the conflicting opinions of both branches for the outer merge to resolve. I think that is a sensible thing to do. The rename destinations of both branches are removed. What happens if ren1_dst (the path one branch wanted to rename src to) were added by the other branch (which wanted to rename src to ren2_dst), causing rename/add conflict between branches (i.e. not the one you worry about in the above FIXME which is about one branch renaming src to ren1_dst while adding an unrelated content to src)? -- 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