Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. Yes. In this particular case the two are not opposing though, rather orthogonal, as they reflect the intrinsic dualism of the concept of "merge commit". Merge commit is both a new state, and history junction, neither of which is more or less valid or essential, and I use both views myself, depending on situation. An electron is both a particle and a wave, and one just uses its side that is more convenient for explanation of the case in hand. I promote features that I routinely need in my workflows, yet respecting the other side of the coin as well, even though I may rarely find this other side useful. I mean, for me, this -c/--cc (let alone -m) output is only confusing, yet I won't be saying that it's somehow less valid than proposed -d. > 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. No need to ask for a new option, as the behavior you describe is already there, and is spelled "git log --diff-merges=first-parent" (--diff-merges=1 for short). > 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. Your concern above seems to be void, so this doesn't hold either. As a side-note though, something like this has been asked recently, as what you describe by --ndfnm should in fact have been what --no-patch does, but surprisingly does not (please recall recent discussion of this issue). > Even if it were a valid world view with wide backing, Apparently it is valid, otherwise there would be no need for diff to first parent at all, let alone "git log --first-parent -p" have used it by default. > the combination "--diff-merges=first-parent --patch" would be less > than ideal presentation for them (due to lack of "--ndfnm"). First, as we figured above, --ndfnm is not needed, and second, me, being one of "them", tries hard to convince you it is the best presentation "them" can get, while "ideal" simply never exists. > And as I already said, it would not be useful without --first-parent > traversal for the worldview git has supported. Yes, you said it earlier in this thread, and as well I already explained how it is useful without --first-parent. > 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. Hopefully I do understand your concerns, yet I believe "--diff-merges=first-parent --patch" is way better for "-d" shortcut than "--first-parent --patch", for the reasons I already explained earlier in this thread. > Shorthands are scarse resources, and we want to be careful before > handing them out. Yep, agreed. I believe I carefully thought it over though, weighing all pros and cons, and thus -d fits nicely among -c and --cc, being yet another frequently desired format for merges, plays nice with -p as well, and is very mnemonic, giving us convenient, user-friendly, and consistent user interface overall. Thanks, -- Sergey Organov
