Sergey Organov <sorganov@xxxxxxxxx> writes: > P.S. I also figure that maybe our divergence comes from the fact that I > consider merge commits to be primarily commits (introducing particular > set of changes, and then having reference to the source of the changes), > whereas you consider them primarily merges (joining two histories, and > then maybe some artificial changes that make merges "evil"). That's why > we often end up agreeing to disagree, as both these points of view seem > pretty valid. It rarely is the case that two opposing world views are equally valid, though. If there were an option that forbids any comparison output from a single parent commit (say --ndfnm "no-diff-for-non-merge"), then those with "merges are the primary thing, single-parent commits on the merged branches are implementation details" worldview would be commonly using "--diff-merges=first-parent --patch --ndfnm" and (1) viewing only the combined effect of merging side branches without seeing noise from individual commits whose effects are already shown in these merges, and (2) traversing the side branches as well, so that merges from side-side branches into the side branches are viewable the same way as merges into the mainline. But because no such option exists and nobody asked for such an option during the whole lifetime of the project, I highly doubt that it is a valid world view with wide backing from the users. Even if it were a valid world view with wide backing, the combination "--diff-merges=first-parent --patch" would be less than ideal presentation for them (due to lack of "--ndfnm"). And as I already said, it would not be useful without --first-parent traversal for the worldview git has supported. That is why I find it of dubious value to let short-and-sweet '-d' be squatted by less than ideal "--diff-merges=first-parent --patch" combination. Shorthands are scarse resources, and we want to be careful before handing them out. Thanks.
