Subject: Re: Reviewing merge commits, was Re: [rPATCH 13/12] Merge branch 'jc/fix-aggressive-protection-2.39'

From: Junio C Hamano <[email-masked]>
Date: Thu, 23 May 2024 07:41:20 -0700

Johannes Schindelin <[email-masked]> 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.

;-)