Junio C Hamano [mailto:gitster@xxxxxxxxx] wrote: > We do not gratuitously break existing implementations. If no conflict is stored > as higher-stage index entries in an index that has your index extension, no > existing implementation can read a conflicted index written by your > implementation and have users resolve conflicts. I'm not suggesting that anybody stop writing >0 stage entries. > When a path originally at A is moved to B on only one branch, and there are > content-level conflicts between the changes made by one branch (while going > from A to B) and by the other branch (while keeping it at A), we would end up > having three stages for path B without any trace of path A. I do not offhand > know how much it helps to learn A in such a situation in the real life, but we are > indeed losing information, and I do not have any problem with an extension that > records in the index the fact that in the two (of the > three) commits involved in the merge, the path was at A. What you've described is true only for a certain class of rename conflicts, for example the rename/edit conflict you've described above. It's also true if you were to rename some item 'a' to 'b' in both branches. But when 'b' is sufficiently dissimilar to become a rewrite, then I end up with a rename of a->b on one side and deleting a and adding b on the other. The result is a mysterious "added by us" conflict: 100644 e2dd530c9f31550a2b0c90773ccde056929d6d66 2 b Worse yet is if I don't do the rename in my side, but I just add a new b so that in theirs I've renamed a to b and in mine I have both a and b. When I do the merge, I'm told I have conflicts, except that I don't: 100644 08d4f831774aed5d4c6cb496affefd4020dce40c 0 b The other branch's b is long gone and exists only as a dirty file in the workdir. > But people have been successfully using existing versions of Git without that > information to merge branches with renames, and resolving the content-level > conflicts. But you aren't afforded the option to resolve content-level conflicts if you don't know where the conflict came from. For example, in a rename 1->2 conflict, we dutifully detect that a was renamed to both b and c and fail, but that fact is never given to the index. This conflict could be fed into a merge tool or, better, automerged, with the user only needing to pick a path: 100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 1 a 100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 3 b 100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 2 c I hate to sound like a broken record here, but without some more data in the index - anywhere, really - any tool that doesn't have the luxury of emitting data about what happened to stdout certainly can't infer anything about what happened in the merge. -ed -- 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