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

Alex Henrie [off-list ref] writes:

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

quoted

Junio C Hamano [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] writes:

[...]

quoted

If we enable "some kind of diff" for "-m", I actually think that by
default "git log -m" should be turned into "log --cc".  As you told
Alex in your response, "log -m -p" is a quite unpleasant format to
read---it is there only because it was the only thing we had before
we invented "-c/--cc".

Please, no! --cc has unfortunate feature of outputting exactly nothing
for a lot of merge commits, causing even more confusion than historical
"-m -p" format.

The best default for -m output is --diff-merges=first-parent. Everybody
is familiar with it, and it's useful.

quoted

But that might be outside the scope of this series.  I dunno, but if
there is no other constraints (like backward compatibility issues),
I have a moderately strong preference to use "--cc" over "-m -p"
from the get go for unconfigured people, rather than forcing
everybody to configure

I rather have strong preference for --diff-merges=first-parent. --cc is
only suitable for Git experts, and they know how to get what they want
anyway. Yep, by using --cc. Why spare yet another short option for that?

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

Honestly --diff-merges=separate is fine. Two weeks ago, when I started
this discussion, I was trying to use `git log -m` and `git show -m` to
find which merge commit introduced a particular change. Extremely
verbose diff output would have been great for that, the confusing part
was just that `git show -m` produced diff output and `git log -m` did
not.

This is not a case in favor of "separate" over "first-parent" as the
default for "-m", right?

"Which merge commit introduced particular change" is exactly what
--diff-merges=1 achieves, so "--diff-merges=separate" was not in fact
needed, as I see it. Moreover, it could have produced wrong positives.
Looks like --diff-merges=1 is a better fit.

Maybe what we really want is a new short option like `git log -m1`
which would both enable diff output and set --diff-merges=1.

Hopefully this will be simply "-m" soon. "-m1" is no-go as optional
arguments to short options is a bad idea. It could have been "--m1", but
I believe that's not needed.

But again, I don't have a strong opinion on which particular diff
output is "the best", so I'm happy to leave that decision to the
experts.

There is no "the best", and at least "first-parent" and "dense-combined"
are to survive, and "dense-combined" already has its "--cc" rather short
variant, so it's logical to give -m the other one, especially as it
already has this meaning when --first-parent is provided as well.

Also, I'm not sure if -c is being in use, and if it isn't, then it could
be changed to produce dense-combined format, especially as one still
have --diff-merges=condensed nowadays anyway, so that -m and -c will
finally give 2 most useful formats.

Overall, I still find a lot of sense in giving "-m" exactly first-parent
default meaning.

Thanks,
-- Sergey Organov

P.S. If generic options machinery were in use, it could have been
possible to say:

  git log -pm

reducing the issue to consistency only. I wonder if anybody have plans
to convert setup_revisions() to parse_options() utility?

On Tue, May 11, 2021 at 12:46 PM Sergey Organov [off-list ref] wrote:

Alex Henrie [off-list ref] writes:

quoted

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

quoted

Junio C Hamano [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] writes:

[...]

quoted

If we enable "some kind of diff" for "-m", I actually think that by
default "git log -m" should be turned into "log --cc".  As you told
Alex in your response, "log -m -p" is a quite unpleasant format to
read---it is there only because it was the only thing we had before
we invented "-c/--cc".

Please, no! --cc has unfortunate feature of outputting exactly nothing
for a lot of merge commits, causing even more confusion than historical
"-m -p" format.

The best default for -m output is --diff-merges=first-parent. Everybody
is familiar with it, and it's useful.

quoted

But that might be outside the scope of this series.  I dunno, but if
there is no other constraints (like backward compatibility issues),
I have a moderately strong preference to use "--cc" over "-m -p"
from the get go for unconfigured people, rather than forcing
everybody to configure

I rather have strong preference for --diff-merges=first-parent. --cc is
only suitable for Git experts, and they know how to get what they want
anyway. Yep, by using --cc. Why spare yet another short option for that?

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

Honestly --diff-merges=separate is fine. Two weeks ago, when I started
this discussion, I was trying to use `git log -m` and `git show -m` to
find which merge commit introduced a particular change. Extremely
verbose diff output would have been great for that, the confusing part
was just that `git show -m` produced diff output and `git log -m` did
not.

This is not a case in favor of "separate" over "first-parent" as the
default for "-m", right?

"Which merge commit introduced particular change" is exactly what
--diff-merges=1 achieves, so "--diff-merges=separate" was not in fact
needed, as I see it. Moreover, it could have produced wrong positives.
Looks like --diff-merges=1 is a better fit.

I didn't know which branch the change came from. If the change came
from the first branch, it would not have appeared under the merge
commit with --diff-merges=first-parent. But the change would
definitely appear with --diff-merges=separate, which enabled me to
identify the merge commit that included it. So yes, this is a case in
favor of "separate" over "first-parent", but it's probably not a
common enough scenario to demand keeping "separate" for -m.

On Tue, May 11, 2021 at 12:31 PM Elijah Newren [off-list ref] wrote:

Interesting.  I have a strong preference for --diff-merges=remerge
(yeah, I know it's not upstream, but it's been ready to submit for
months, but just backed up behind the other ort changes.  Sorry, I
can't push those through any faster).  I've had others using it for
about 9 months now.

--diff-merges=remerge is the default I would expect when no options
have been configured or passed on the command line (although it would
not have helped in the scenario I described above). I look forward to
using it!

-Alex