Re: so/diff-merges-more (was Re: What's cooking in git.git (Feb 2023, #01; Thu, 2))

[Junio C Hamano <gitster@pobox.com>]

Sergey Organov <sorganov@gmail.com> writes:

> We are walking in rounds here. Let me try to find at least some common
> ground. Could we try to agree on *one* of these 2 mutually exclusive
> statements, please:
>
> 1. Current -m behavior is useful
>
> 2. Current -m behavior is useless
>
> To me it looks like Junio thinks 1 is the case, and you, Glen, think
> it's 2 that is the case, ...

I agree you two are going around in circles and it may be time to
agree to disagree and move on.

I am not Glen but I do not think anybody is arguing "-m" that
does not do anything by itself is useful.  By definition, without
help with "-p", it is a no-op, so by itself, it cannot be useful.

The reason why I am not enthused by your series is because changing
behaviour of "-m" can be harmful, because "-m -p" is not the first
choice people would make when they choose to view what a merge
commit did.

Back when "-m" was invented (yes, "-p" came first before "-m"),
people were fairly content with "git log -p" that shows only
individual changes.  After all, merges were to integrate what these
individual changes on each side of the merged history did.  And you
need to be aware that "-c" and "--cc" did not exist, let alone
"--remerge-diff", even as a concept.  The philosophy of Git back
then stressed that these parts of Git were working as building
blocks to feed necessary data to be used by tools people who were
working at higher, end-user facing layers, would write.  And because
we ourselves have been mostly content with "git log -p" output that
omits patches for merge commits so far, a quick approach to give
output for such tools to consume without losing information was what
became "-m -p" output that shows pairwise diffs that such tools can
combine or do whatever they want to do.  This choice was also
influenced by the fact that we considered stronger than we do now
that all sides of a merge are equal---the idea that the first parent
chain was somehow special came much leter with the "--first-parent"
option.

So, given that background, "-m" that came as a modifier for what
happens (only) when "-p" was in use, is perfectly understandable.
In hindsight, it may appear to you that it should imply "-p", and
that it is an oversight that it does not imply it.

But it is more like how "git log --histogram" does not produce patch
output.  The mental model that allows it is that "--histogram" is to
affect the way how "-p" computes the diff---a purist in you may
argue that it should also imply "-p", but in reality, nobody
complained that "--histogram" does not imply "-p", probably because
nobody sane would say "--histogram" when they do not mean to show
diff out of "git log" anyway.

As somebody who saw how various options were invented while they
were added to the system, I view "-m" as an option to decide what
"-p" does when encountered a merge commit, and do not find it any
more odd that it is a no-op without "-p" or it does not imply "-p"
than "--histogram" vs "-p".