Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Much of what is tricky about these merges > happens outside conflict markers. Yes. In other words, what you do not see in these outputs can be leaving semantic conflicts unresolved. If we made a change to a location where there wasn't a textual conflict (i.e., making an evil merge) in order to adjust for a semantic differences (e.g., they added a callsite to a function whose signature we updated), any of "git show --cc", "git range-diff", and "git show --remerge-diff" would show. If you failed to do so and introduced a bug (and worse yet, unlike "oh, we now require one more argument to the function" that compilers would catch for us, there are differences that compilers would not notice), none of the three will show. > If it was up to me to verify such fixes, short of using Git and validating > the correctness by performing the merge independently instead of trying to > accomplish the validation by looking at a plain-text mail, I would compare > the diff of `maint-2.39` to the diff of `maint-2.40`. Something like this > [*1*]: > ... > Both the remerge-diff and the range-diff output do nothing, though, to > help verifying that no-longer-needed `#include`s are removed (you can see > that `#include "copy.h"` was removed from `hook.c`, but if that had been > missed there would be no indicator thereof). In short, you are agreeing that between "remerge-diff" and "range-diff" there is no difference in power to let you notice what is *not* there, and I am agreeing to your "what is *not* there is often more problematic", so we are on the same page. I do not think I am married to "remerge-diff" output, but it being the same form of the familiar "single-parent" patch, I personally find it far easier to read than "diff of diff". We may differ at that point, but it does not matter, as neither of our preferred format is adequate for the job. ;-)
