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

Junio C Hamano [off-list ref] writes:

Sergey Organov [off-list ref] writes:

quoted

Fix long standing inconsistency between -c/--cc that do imply -p, on
one side, and -m that did not imply -p, on the other side.

After this patch

  git log -m

will start to produce diffs without need to provide -p as well, that
improves both consistency and usability. It gets even more useful if
one sets "log.diffMerges" configuration variable to "first-parent" to
force -m produce usual diff with respect to first parent only.

Please make sure that you clearly state that you do not blindly
force --patch output in the proposed log message.  Explicitly
mentioning that "git log --stat -m" would not give a patch but just
diffstat would be assuring.

Also, avoid "-p" in the title.  "let -m imply diff generation" might
be a good compromise.

What --cc/-c implies is to show some kind of diff for merges
(dense_combined_merges, combine_merges and !ignore_merges are the
members of the revs field that controls how merge commits) and they
ask for specific kind of diff is shown.  So "-c/--cc imply -p" is
quite wrong (you never get straight --patch output for merges when
you give -c/--cc---you get combined diff).  In a sense, you could
say -c/--cc implies -m (i.e. do show some kind of diff for merges).

Taken together, perhaps:

    Subject: diff: let -m imply diff generation

    The "-c/--cc" options to "git log" asks for merges to be shown
    with patch-like output, implicitly enabling the "-m" option
    (which is used to tell "do not ignore merge commits when showing
    patches).  However, the opposite is not true; giving "-m" alone
    does not tell "git log" that the user wants some form of patches.
    
    Make "-m" imply "we want some form of diff output", so that "git
    log -m" would behave identically to "git log -m -p".  When the
    user explicitly asks for what kind of diff output is desired,
    e.g. "git log -m --stat", there is no need to imply anything,
    specifically, do NOT blindly turn on the "-p: option to turn it
    into "git log -m --stat -p:.

or something like that.

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

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

Also this needs a test to ensure that is what happens.  Having a
test for "log -m" and another for "log -m --stat" would be
sufficient.

And in the context of this step, the rename of the member in the
previous step makes quite a lot of sense.

Thanks for working on this topic.