Jonathan Nieder <jrnie...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
