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

Jonathan Nieder <jrnieder@gmail.com> writes:

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.

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.

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.

But "--cc/-c" does not have anything to do with Tapsell's "security worries". The only real audit he can do is with "log -m -p", possibly with --first-parent (only if he trusts his first-parent history).

The "recreate mechanical merge and compare recorded merge against it" mode may highlight a malicious merger, but it will not show a cleanly merged hunk of malicious code in the merge, so it cannot be used with --first-parent when used as a "security audit tool". Tapsell still needs to drill down to the merged side branch that introduced the malicious change that merged cleanly with "-p".