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

Junio C Hamano [off-list ref] writes:

Elijah Newren [off-list ref] writes:

quoted

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

quoted

...

I think --cc is a lot better than -m for helping you find what users
changed when they did the merge, 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.

quoted

Overall, let's rather make -m give diff to the first parent by default.
Simple. Useful. Not confusing.

I think it's confusing.

I do not think it is particularly confusing---after all, it shows
"here is a comparison between two trees" the users are familiar with
in a single strand of pearls.

Moreover, it's comparison between two most natural trees, the same trees
as for non-merge commits.

But I do think that it is an utterly misleading option to show
merges in general.  When "log" is used with the "--first-parent"
traversal, "compare with the first parent to show everything the
side branch did" is an acceptable alternative, but even there, it is
far less suitable than the "remerge" or "cc", I would think, as the
default format.

What I still fail to see is why somebody wants to mix traversal rules
with representation of merge commits, sorry.

If I want to see merges in --cc, I want them in --cc, no matter which
way I get to particular commit through the DAG. If I want to see them in
--diff-merges=1, I want them this way, no matter how I happened to get
to particular commit.

Is it more likely that I want to see merges in --diff-merges=1 when I
use --first-parent? Yes, of course! That's why --first-parent implies
--diff-merges=1. Vice versa? No, why?

Thanks,

-- Sergey Organov