Re: [PATCH 00/26] git-log: implement new --diff-merge options

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 9, 2020, 20:53 UTC
Message-ID: <xmqqo8j21z1n.fsf@gitster.c.googlers.com>
In-Reply-To: <87v9dbf4xd.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 15 quoted lines

>>> If I were to decide now with hindsight, perhaps I'd make "--cc" and
>>> "-m" imply "-p" only for merge commits, and the user can explicitly
>>> give "--cc -p" and "-m -p" to ask patches for single-parent commits
>>> to be shown as well.
>>
>> After "now with hindsight", I need to add "and without having to
>> worry about backward compatibility issues" here.  IOW, the above is
>> not my recommendation.  It would be the other way around: "--cc"
>> implies "-p" for both merges and non-merges, "-m" implies "-p" for
>> both merges and non-merges.  It is acceptable to add a new option
>> "--no-patch-for-non-merge" so that the user can ask to see only the
>> combined diff for merges and no patches for individual commits.
>
> OK, so, do we decide that -c/--cc must continue to imply -p and thus
> request diffs for everything?

My vote goes to keep the above behaviour as-is for compatibility, and probably match what happens when -m is given instead of -c/--cc, if somebody cares enough about "-c/--cc/-m discrepancy".

> That said, -m is useless, period. It'd likely have some merit in
> plumbing, but definitely not in porcelain. So I'm inclined to let it
> rest in peace indeed, dying.

That is fine by me as well.

I do not speak for others, though ;-)