Junio C Hamano [mailto:gister@xxxxxxxxx] wrote: > As long as > the format will be backward compatible to allow existing users use existing tools > to deal with cases the existing tools can handle, then that is OK. I didn't get that > impression which is where my "non starter" came from. I see now. Thank you for the clarification. I apologize if I was not clear about this; indeed, the duplication of data in my proposed extension was specifically to avoid any compatibility problems amongst clients. In particular, when we have a rename in ours, edit in theirs conflict, we store the conflict at the new (ours) path. If, for example, I rename a->b in my branch and merge a branch that edits a: mode hash 1 b mode hash 2 b mode hash 3 b This prohibits us from storing anything else in the theirs side at that path, so if I were to have added b in their branch in addition to modifying b, I cannot record it. I was assuming that any change to this behavior would be a breaking one, which is where the new section came from. > * Path A may have only stage #1, while path B and C has only stage > #2 and stage #3 (the user would have to notice these three > correspond to each other, and resolve manually). > > You would want to annotate "B at stage #2 seems to have been at A > in the original" (similarly for C#3) if you choose to do so. If we're going to make changes to the way conflicts are recorded in the main index, then I would prefer this approach. It is unambiguous and all data about all sides are recorded, including the names that items had in their respective branches. I would think that this might be a burden on current tools, however. Now if I rename a->b my just my branch, my conflict will be recorded as: mode hash 1 a mode hash 2 b mode hash 3 a And current git-status will not look at any rename annotations to know how to report this. However, maybe this is not as big a problem as I'm concerned it would be. > * You can choose to favor "our" choice, and have path B with three > stages (if we guessed wrong and the user wants to move it to C, > the user can resolve and then "git mv" the path). I think this approach suffers from the drawback that the current approach has, wherein this conflicts when they had path B, also, as noted above. I think that if you were to put both B and C with all three stages, this would be problematic for the same reason. > *1* Instead of a three-way merge that inspects only the endpoints, > you might get a better rename trail if you looked at the > histories of both branches. It would be a lot more expensive > than the simple three-way, but burning CPU cycles is better than > burning human neurons. For the record, I like this approach very much. It's not something that libgit2 will be able to tackle in the near future; we're in a sort of walk-before-you-can-run situation with merge at the moment, as you can probably see. But any improvement that avoids burning neurons is a valuable one. 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