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

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

Jonathan Nieder <jrnieder@gmail.com> writes:

> That's why if you want to review the code you are pulling in as a
> whole, it is worthwhile to do
>
> 	git diff HEAD...FETCH_HEAD
>
> That is how you ask "What code changes does FETCH_HEAD introduce?"
> before putting your stamp of approval on them by merging and pushing
> out the result.

And the only way to retroactively review that a merge C did not do
anything funly is to check "git diff C^1 C", assuming that you
already trust C^1, the state before you performed the merge.
Incidentally, this works for non-merge commits just as well.

"git log -m -p" is not the default because most of the time people
are not interested in seeing what it shows over "--cc" or "-c".  It
is a repetition of what you would get from individual patches on the
side branch merged that you will later see in the traversal of that
command. "--cc/-c" gives a representation for tricky merge cases
where people could likely have made a mistake, or had correctly
resolved semantic conflicts (e.g. one side renames a function, the
other side adds a callsite, the merge result renames the function
new caller calls).

For the purpose of a "merge audit" John seems to want, the only way
is to wade through "log -m -p" output.