Jonathan Nieder <jrnie...@gmail.com> writes:
> The thing is, I'm not convinced this is a bad default. "Shows no diff
> at all for merges" is easy for a person to understand. It is much
> easier to understand its limitations than -c and --cc.
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
> For that
> reason, it is a much *better* default for security than --cc or -c
> (even though I believe one of the latter would be a better default for
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
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
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".
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