Sergey Organov <sorganov@xxxxxxxxx> writes: >> I thought I already said this, but in case I didn't, I think >> "--diff-merges=separate" should imply "some kind of diff", and not >> necessarily "-p". > > Is this a more polite way to say "no"? If not, how is it relevant for > -m, now being a synonym for --diff-merges=on? Sorry, I didn't mean to say "no" to anything. I wrote 'separate' not because I wanted to special case that (and treat others like 'on' differently), but simply because I didn't want to write "--diff-merges=<anything>" as "off/no" should not imply "show some kind of diff". > As for particular idea, I'll repeat myself as well and say that I'm > still against implying anything by any off --diff-merges, and even more > against implying something that affects non-merge commits. --diff-merges > are not convenience options that need to be short yet give specific > functionality, so there is no place for additional implications. So -m (a shorthand for --diff-merges=on) should not imply any patch generation, you mean? It matches what we seem to have agreed on to be the purist view in a few messages ago. --diff-merges controls which parent(s) comparison is made against in a merge, -p/--cc/--raw/--stat etc. control how the result of that comparison is expressed. But I also remember that we agreed that the purist view design was cumbersome to use, so --diff-merges=<anything but no> implying "show some kind of diff" is OK, plus if nobody says "what kind" via the command line with -p/--cc/--raw/--stat etc., it is OK to default to '-p'. One thing I think our unnecessary "disagreement" comes from is that among "-m", "--cc", "-c", you say "-m" is the only thing that does not imply "-p", but I do not view "--cc" and "-c" as sitting next to "-m" at all in the first place. "-m" is on the "which parent(s) to compare with" side, while "--cc" and "-c" are "now you decided which parent(s) to compare with, how does the result of comparison presented?" side. And because "--cc"/"-c" explicitly wants to work on merge commits (because it naturally degenerates to simple "--patch" for non merges), THEY are made to imply "-m" (i.e. compare with all parents). So from my point of view, "--cc/-c" implying "-m" has no relevance to whether "-m" should or should not imply "some kind of comparison should be shown". But because we agreed that we want to bend the purist view for usability and included cc/c among the choices diff-merges=<choice> can take, I think -m (but not log.diffMerges=no case) should imply "we should show some kind of patch". Which would mean that unless when log.diffMerges or --diff-merges say off/no, and unless there is any option to specify how the result of comparison should bepresented on the command line: - when log.diffMerges or --diff-merges say cc or c, default to --cc or -c. - otherwise,default to --patch. is what I think should happen. But the reason I think so is not because "--cc" and "-c" gives output without "-m" (i.e. "-p" does not imply "-m" and it should not).
