Re: git log -p unexpected behaviour - security risk?

[John Szakmeister <john@szakmeister.net>]

On Sun, Apr 21, 2013 at 2:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> The thing is, I'm not convinced this is a bad default.  "Shows no diff
>> at all for merges" is easy for a person to understand.  It is much
>> easier to understand its limitations than -c and --cc.
>
> Making "log -p -m" a default before -c/--cc was introduced would
> have been the stupidest thing to do, as it would make the command
> mostly useless.  Nobody would want to see repetitious output from a
> merge that he would eventually get when the traversal drills down to
> individual commits on the merged side branch.
>
> When I added -c/--cc, I contemplated making -p imply --cc, but
> decided against it primarily because it is a change in traditional
> behaviour, and it is easy for users to say --cc instead of -p from
> the command line.

FWIW, security aside, I would've like to have seen that.  I find it
confusing that merge commits that introduce code don't have a diff
shown when using -p.  And I find it hard to remember --cc.  BTW,
what's the mnemonic for it?  -p => patch, --cc => ?

> On the other hand, "show" was a newer command and it was easy to
> turn its default to --cc without having to worry too much about
> existing users.
>
>> For that
>> reason, it is a much *better* default for security than --cc or -c
>> (even though I believe one of the latter would be a better default for
>> convenience).
>
> Yes.  I do not fundamentally oppose to the idea of "log -p" to imply
> "log --cc" when "-m" is not given ("log -p -m" is specifically
> declining the combined diff simplification).  It may be a usability
> improvement.

Would you consider such a patch?

-John