Re: Why doesn't `git log -m` imply `-p`?

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2021, 00:20 UTC
Message-ID: <xmqqy2cu58vo.fsf@gitster.g>
In-Reply-To: <87r1imbmzz.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 6 quoted lines

>> I thought I already said this, but in case I didn't, I think
>> "--diff-merges=separate" should imply "some kind of diff", and not
>> necessarily "-p".
>
> Is this a more polite way to say "no"? If not, how is it relevant for
> -m, now being a synonym for --diff-merges=on?

Sorry, I didn't mean to say "no" to anything.

I wrote 'separate' not because I wanted to special case that (and treat others like 'on' differently), but simply because I didn't want to write "--diff-merges=<anything>" as "off/no" should not imply "show some kind of diff".

Show 5 quoted lines

> As for particular idea, I'll repeat myself as well and say that I'm
> still against implying anything by any off --diff-merges, and even more
> against implying something that affects non-merge commits. --diff-merges
> are not convenience options that need to be short yet give specific
> functionality, so there is no place for additional implications.

So -m (a shorthand for --diff-merges=on) should not imply any patch generation, you mean? It matches what we seem to have agreed on to be the purist view in a few messages ago. --diff-merges controls which parent(s) comparison is made against in a merge, -p/--cc/--raw/--stat etc. control how the result of that comparison is expressed.

But I also remember that we agreed that the purist view design was cumbersome to use, so --diff-merges=<anything but no> implying "show some kind of diff" is OK, plus if nobody says "what kind" via the command line with -p/--cc/--raw/--stat etc., it is OK to default to '-p'.

One thing I think our unnecessary "disagreement" comes from is that among "-m", "--cc", "-c", you say "-m" is the only thing that does not imply "-p", but I do not view "--cc" and "-c" as sitting next to "-m" at all in the first place.

"-m" is on the "which parent(s) to compare with" side, while "--cc" and "-c" are "now you decided which parent(s) to compare with, how does the result of comparison presented?" side. And because "--cc"/"-c" explicitly wants to work on merge commits (because it naturally degenerates to simple "--patch" for non merges), THEY are made to imply "-m" (i.e. compare with all parents).

So from my point of view, "--cc/-c" implying "-m" has no relevance to whether "-m" should or should not imply "some kind of comparison should be shown".

But because we agreed that we want to bend the purist view for usability and included cc/c among the choices diff-merges=<choice> can take, I think -m (but not log.diffMerges=no case) should imply "we should show some kind of patch".

Which would mean that unless when log.diffMerges or --diff-merges say off/no, and unless there is any option to specify how the result of comparison should bepresented on the command line:

 - when log.diffMerges or --diff-merges say cc or c, default to --cc
   or -c.

 - otherwise,default to --patch.

is what I think should happen. But the reason I think so is not because "--cc" and "-c" gives output without "-m" (i.e. "-p" does not imply "-m" and it should not).