Junio C Hamano [mailto:gitster@xxxxxxxxx] wrote: > I do not offhand see anything particularly stupid; a new optional index extension > section CACHE_EXT_RENAME_CONFLICT might be a good addition. > > Is "one side moves A to B while the other side moves it to C" the only case, or is > it just an example? Off the top of my head, "one side moves A to x while the > other side moves B to x/y" would also be something we would want to know. I > am sure there are other cases that need to be considered. Yes, that was just an example. Certainly I was intending that all conflicts that arose from renames would end up here since one can't really reason why the merge tool created a conflict by looking at the index alone - even knowing the merge tool's similarity algorithms, this would be awfully expensive to piece back together, even if the index did contain non-zero stage entries for all the items that were involved in the conflicts. That said, my rather naive initial thought was that we could repeat *all* conflicts in this area. This would give tools that knew how to understand this the ability to go to a single place for conflict data, rather than producing some merge of high-stage entries that comprise non-rename conflicts and data from the rename conflict area for rename conflicts. Thanks- -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