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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2013, 18:25 UTC
Message-ID: <7vzjwru4ev.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130421102150.GJ10429@elie.Belkin>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 8 quoted lines

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