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

From: Junio C Hamano <[email-masked]>
Date: Tue, 08 Dec 2020 20:18:03 -0800

Elijah Newren <[email-masked]> writes:

>> If I can run "git log --some-options master..next" (or more
>> realistically, over the range ko/next..next) to get individual
>> commits (without patch) and merges (only when --cc gives some
>> interesting nearby-changes), I would be very happy.  But is there a
>> set of options that lets me do so?
>
> So, you're saying you changed your mind since five years ago?[1]  Or
> that what you said five years ago is still valid, but you'd appreciate
> more/different options that allow this new thing?
>
> [1] https://lore.kernel.org/git/[email-masked]/

Sorry, but I am not seeing in [1] anything that relates to the above
"want to see --cc patch for merge but just log message for single
parent commit". 5 years is a long time even in Git timescale, so I
would not be surprised if I changed my mind over time, but I am not
sure what opinion on the matter you think I expressed back then.

"git log --cc master..next" shows all commits' log messages, patch
for each single-parent commit, and combined-dense patch for each
merge.  There is no option to squelch the patch for only single
parent commits.  It may not be such a bad thing to have as an extra
option.

So, I think what I am saying is that ...

> > ...  As I said, I'm not sure why
> > anyone would ever want to see diffs for merges and not for normal
> > commits, the closest useful thing I can imagine is commit messages +
> > diffs for just merges, stripping the normal commits.

... I see use for such a feature (assuming that you didn't mean by
"diffs for merges" a regular "--first-parent -p" patch, but meant to
say "--cc" patch) in my workflow.  I'd review "log ko/next..next"
before deciding to push out the day's integration of 'next', and at
that point, I trust individual commits that came from contributors
well enough (otherwise I wouldn't be merging them to 'next'), but I
would appreciate the last chance to re-examine conflict resolutions
in merges.

It does not mean that I do not like the current behaviour that
"--cc" always implies "-p"; it is convenient.  It's just I find the
lack of feature slightly less than ideal, but I do not care deeply
enough to design how to express such a feature from the command
line.