When a rename conflict occurs, the information about the conflict is written to stdout and the index is updated as if the conflict were a simpler conflict that did not involve renames. This doesn't give a lot of information to users after the fact - a status of "added in ours" does not provide a lot of details about what occurred. In reimplementations, we face a similar challenge. Unfortunately, we can't simply print the output to the console, we would like to provide this information back to the caller by some mechanism. My preference would be to return this information in the index - so that the results of "unpack trees" (if you will) was a single data structure (the index) and so that we could persist this information to disk. I've been considering the idea of an extension that contains more detailed data about conflicts, but I certainly wouldn't want to proceed without discussing this here further. I would propose that we store the data about the file in conflict as it occurred through the renames. For example, in a rename 1->2 conflict where A was renamed to both B and C, you would have a single conflict entry containing the data for A, B and C. This would allow us to provide more detailed information to the user - and allow them to (say) choose a single name to proceed with. Is this something that has value to core git as well? Alternately, is there something particularly stupid about this proposal? 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