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

From: Sergey Organov <sorganov@gmail.com>
Date: Mar 8, 2023, 22:19 UTC
Message-ID: <87jzzqzy20.fsf@osv.gnss.ru>
In-Reply-To: <xmqqzg8ozbuh.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 15 quoted lines

> 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'm willing not only to disagree, but even to agree on any of these 2 options, but I can't (dis)agree on both, as they are mutually exclusive. Yeah, it could be seen as my personal problem, but, well...

> I am not Glen but I do not think anybody is arguing "-m" that does not
> do anything by itself is useful.

I'm sorry, I still can't quite understand your position.

Do you think exact current behavior of "-m" is useful, or is it useless?

> By definition, without help with "-p", it is a no-op, so by itself, it
> cannot be useful.

No, it's not a no-op as I see it, it's just that its effect is hidden till "-p" is specified as well, and that's the exact "current behavior" that I'm asking about. Is it useful, or not?

Please let me remind you that at previous rounds there was the commit that reverted my earlier "Let -m imply -p" patch, and that revert insists lone "-m" is useful, and you accepted it, and pointed me to the explanation there, telling me that there is pretty solid use-case for a lone "-m".

I agreed with you at that time, and then followed with current patch series created exactly based on that earlier agreement, that now somehow turns back to disagreement, leaving me sad and confused.

Provided current -m behavior is indeed useful, in these series:

1. Current -m behavior is now supported by --diff-merges (as presumably
   being useful.)

2. Implying -p by -m is made an option (not to break those presumably
   valid uses.)

And now these series are to be rejected on the ground that current "-m" behavior is useless? Then let's revert the revert?

Show 5 quoted lines

>
> 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.

That's your view on merge commits, but there is another view out there, where "-m -p" is exactly the first choice, provided "-m" is configured to give diff with respect to the first parent only. I want to have the same convenience of saying just "log -m" as you already have with "log -c". What's wrong about it?

I realize there is a large group here that looks at merge commits differently, and I respect their choice to show other kinds of information that could be derived from merges. What I can't understand is why another view is assumed to be a second-class citizen, sorry.

Please also note that I made behavior change an option, exactly not to harm those who doesn't need it, even though it's not clear how those who don't use -m are to be affected anyway.

Show 7 quoted lines

>
> 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.

Yep, I'm aware of all that history now, as I went over it back and forth a few times already, trying to figure out what't the actual ground behind desire to *keep* "-m" different from the rest of similar options, but still found none.

[...]

> 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.

My point is that the story with -c, or --cc is roughly the same, and that you yourself fixed --cc once upon a time to imply -p, so it's especially confusing for me that you are now in opposition to similar change to "-m".

Show 8 quoted lines

>
> 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.

Do you then think that making -c/--cc imply "-p" was a mistake in the first place, and you try to hold me back from doing the same mistake?

Show 5 quoted lines

> 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".

It's fine to view "-m" this way, but how do you view "-c" then? If differently, then why?

In other words, in the above sentence, among "--histogram -m -c", you effectively group "(--histogram -m) -c" by leaving -c out of consideration, whereas more natural grouping is rather "--histogram (-m -c)", that'd leave --histogram out of consideration.

Overall, my point is that, provided we do care about consistency of Git UI, it's -m and -c that are to be treated the same, and it's much less relevant if any of them matches treatment of --histogram.

Thanks, -- Sergey Organov