Sergey Organov <sorganov@xxxxxxxxx> writes: > We are walking in rounds here. Let me try to find at least some common > ground. Could we try to agree on *one* of these 2 mutually exclusive > statements, please: > > 1. Current -m behavior is useful > > 2. Current -m behavior is useless > > To me it looks like Junio thinks 1 is the case, and you, Glen, think > it's 2 that is the case, ... I agree you two are going around in circles and it may be time to agree to disagree and move on. I am not Glen but I do not think anybody is arguing "-m" that does not do anything by itself is useful. By definition, without help with "-p", it is a no-op, so by itself, it cannot be useful. The reason why I am not enthused by your series is because changing behaviour of "-m" can be harmful, because "-m -p" is not the first choice people would make when they choose to view what a merge commit did. Back when "-m" was invented (yes, "-p" came first before "-m"), people were fairly content with "git log -p" that shows only individual changes. After all, merges were to integrate what these individual changes on each side of the merged history did. And you need to be aware that "-c" and "--cc" did not exist, let alone "--remerge-diff", even as a concept. The philosophy of Git back then stressed that these parts of Git were working as building blocks to feed necessary data to be used by tools people who were working at higher, end-user facing layers, would write. And because we ourselves have been mostly content with "git log -p" output that omits patches for merge commits so far, a quick approach to give output for such tools to consume without losing information was what became "-m -p" output that shows pairwise diffs that such tools can combine or do whatever they want to do. This choice was also influenced by the fact that we considered stronger than we do now that all sides of a merge are equal---the idea that the first parent chain was somehow special came much leter with the "--first-parent" option. So, given that background, "-m" that came as a modifier for what happens (only) when "-p" was in use, is perfectly understandable. In hindsight, it may appear to you that it should imply "-p", and that it is an oversight that it does not imply it. But it is more like how "git log --histogram" does not produce patch output. The mental model that allows it is that "--histogram" is to affect the way how "-p" computes the diff---a purist in you may argue that it should also imply "-p", but in reality, nobody complained that "--histogram" does not imply "-p", probably because nobody sane would say "--histogram" when they do not mean to show diff out of "git log" anyway. As somebody who saw how various options were invented while they were added to the system, I view "-m" as an option to decide what "-p" does when encountered a merge commit, and do not find it any more odd that it is a no-op without "-p" or it does not imply "-p" than "--histogram" vs "-p".
