Jonathan Nieder <> 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.  
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to