Re: [PATCH 6/6] diff-merges: let -m imply -p

Elijah Newren [off-list ref] writes:

On Tue, May 11, 2021 at 12:00 PM Sergey Organov [off-list ref] wrote:

quoted

Elijah Newren [off-list ref] writes:

quoted

On Tue, May 11, 2021 at 7:03 AM Sergey Organov [off-list ref] wrote:

quoted

Junio C Hamano [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] writes:

[...]

quoted

If we enable "some kind of diff" for "-m", I actually think that by
default "git log -m" should be turned into "log --cc".  As you told
Alex in your response, "log -m -p" is a quite unpleasant format to
read---it is there only because it was the only thing we had before
we invented "-c/--cc".

Please, no! --cc has unfortunate feature of outputting exactly nothing
for a lot of merge commits, causing even more confusion than historical
"-m -p" format.

The best default for -m output is --diff-merges=first-parent. Everybody
is familiar with it, and it's useful.

quoted

But that might be outside the scope of this series.  I dunno, but if
there is no other constraints (like backward compatibility issues),
I have a moderately strong preference to use "--cc" over "-m -p"
from the get go for unconfigured people, rather than forcing
everybody to configure

I rather have strong preference for --diff-merges=first-parent. --cc is
only suitable for Git experts, and they know how to get what they want
anyway. Yep, by using --cc. Why spare yet another short option for that?

Interesting.  I have a strong preference for --diff-merges=remerge
(yeah, I know it's not upstream, but it's been ready to submit for
months, but just backed up behind the other ort changes.  Sorry, I
can't push those through any faster).  I've had others using it for
about 9 months now.

Once somebody uses it for 9 months and starts to understand what it is
and really loves it, she can still set log.diffMerges=remerge (new
feature) and have fun.

quoted

I think --cc is a lot better than -m for helping you find what users
changed when they did the merge,

Yes, but it doesn't mean it should be the default.

I didn't say it should be.

quoted

In my workflows, the first thing that matters is what commit did what
changes on the current branch. I don't typically care what the user
changed during the merge operation, only about the result. If I do care,
then only after I find the merge commit is responsible, and I can then
use --cc if I want to.

quoted

but I agree the format is somewhat difficult for many users to
understand. (--diff-merges=remerge, or --remerge-diff, fixes these
problems, IMO.) I think --diff-merges=first-parent, while fine when
explicitly requested on the command line, would be wildly misleading
as a default because it would attribute changes to a merge commit that
were made elsewhere.

No, it's exactly this merge commit that made these changes to the
current branch. The changes you refer to have been made on another
branch, and not by this particular merge commit, and we fortunately have
the reference to those commits through the second parent of this one.

If you only care about "what introduced these changes to the current
branch", then it's not only the diff against second parent that is
irrelevant: ALL commits that are part of the history only via the
second or later parents are also irrelevant and thus you should be
using --first-parent when asking this question.  That changes both
history traversal and the diff output.

No, it's exactly why I don't always want --first-parent. I want to
traverse *all* the history, yet to see what's changed by every commit on
*this* branch in the process of traversal, be it a merge on not a merge
commit.

Thanks,

-- Sergey Organov