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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> 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.