On Sun, Apr 21, 2013 at 2:42 PM, Junio C Hamano <gits...@pobox.com> wrote: > 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.
FWIW, security aside, I would've like to have seen that. I find it confusing that merge commits that introduce code don't have a diff shown when using -p. And I find it hard to remember --cc. BTW, what's the mnemonic for it? -p => patch, --cc => ? > 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. > >> 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 >> convenience). > > 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. Would you consider such a patch? -John -- 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