Thomas Rast <tr@xxxxxxxxxxxxx> writes: > log --remerge-diff: show what the conflict resolution changed Yay ;-) > This series explores another angle, which I call "remerge diff". It > works by re-doing the merge in core, using features from patches 1-3 > and 7. Likely that will result in conflicts, which are formatted in > the usual <<<<<<< way. Then it diffs this "remerge" against the > merge's tree that is recorded in history. Yup, that is the obvious way to recreate what would have been shown to the person who recorded the merge result. I like that approach. > So I would welcome comments, and/or better ideas, on the following > proposed resolution: > > * Implement what I described last, to take care of delete/modify > conflicts. Naively, I would have thought that - If the recorded result of the merge does not have the path, then show the deletion of the contents relative to the side that modified it. - If the recorded result of the merge has the path, then show the change between the side that modified it and the recorded result. might be more useful. Then we will know what we lost in full (if the recorded result is to "delete" it), but it is very likely that we won't see anything if the recorded result blindly took what the modifying side left. Comparing with the synthetic stages 2+3 will at least show us there was something funky going on, so your approach would be reasonable in this case. > * Punt on more complex conflicts, by removing those files from the > index, and emitting a warning about those files instead. Sensible. -- 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