Sergey Organov <sorganov@xxxxxxxxx> writes: > Glen Choo <chooglen@xxxxxxxxxx> writes: > >> Sergey Organov <sorganov@xxxxxxxxx> writes: >> >>> I already agreed long ago that to be on the safe side we shouldn't >>> simply change -m nowadays, and addressed that concern by putting -m >>> behavior change under configuration option in the current series. So >>> what's the reason of rejection? >> >> Before we start talking in circles again, I think the responses >> elsewhere in the thread still accurately capture mine and Junio's >> views, e.g.: >> >> https://lore.kernel.org/git/xmqqedr28wwb.fsf@gitster.g >> https://lore.kernel.org/git/kl6lr0v2i0gn.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > There were no any response from you to my recent very direct question > (that Junio did somewhat address), but what I figured from your and > Junio explanation so far looks like: Yes, thank you for summarizing the discussion. I think the following sums up my position quite accurately, and I found this very helpful. > 1. The fact that -m does not imply -p is a mistake. There is no any > reasons this exact behavior could be useful. As such, it does not > make sense to support this exact behavior in --diff-merges. So the > reject of --diff-merges=[no-]hide. Yes. > 2. This mistake is too dangerous to fix due to subtle compatibility > problems, so we can't just fix -m behavior. Thus the reject of my > earlier patch "let -m imply -p". Yes, unfortunately. If we didn't have compatibility problems, "-m imply -p" would be very good IMO. I am not that hopeful, but perhaps there are ways to get users to move off this compatibility problem. It would be something we would have to learn as a project though, it is not a problem unique to this series. > 3. Moving behavior change under option is not worth it, as nobody > presumably needs this fixed -m behavior anyway (at least among 2 > persons that are actually opposing the changes). So the reject > of "add diffMerges-m-imply-p configuration option" patch. Yes, given how specific the option is (I think it would be the only config option that exists to change the behavior of a CLI option) I don't think the option is worth it in light of alternatives like a new "-d" flag or supporting "-mp". > 4. Staring in the face inconsistency between -m and the rest > of short diff-merge options is not significant enough to reconsider > any of the above rejects. Yes. Git carries many such inconsistencies. > Did I outline your positions correctly and to the full extent? Anything > else I forgot? I cannot think of anything else. Thank you. > I want to make sure I got it exactly right, as I'd still like to tweak > my proposals, and I'd like to avoid the troubles I got into as much as > possible. Thanks. I hope that there is a good way forward for your proposals. > > Thanks, > -- Sergey Organov
