Sergey Organov <sorganov@xxxxxxxxx> writes: >> but I have been under the impression that the remainder were OK >> clean-ups. Perhaps it is mostly because I read them so long ago and >> forgot the details X-<. > > It's not a cleanup, it's rather adding missed feature that allows to get > precise '-m' behavior with --diff-merges. > ... > However, by making such decision we lost ability to provide exact > behavior of -m using --diff-merges= set of options. This has been > pointed out later to me in the list, and felt obliged to finish > implementation by providing the feature. > > --diff-merges=hide > > is exactly that. This is exactly the "immortaliz[ing] a mistake" that I mentioned upthread, by turning a UX wart (-m doesn't imply -p) that neither of us likes into a feature. I'd be in favor of getting rid of the wart altogether (i.e. let's find a path that lets us make -m imply -p in the future), but not rebranding it as a feature. >>> I'm not convinced that the series makes sense without >>> "log.diffMerges-m-imply-p": >>> >>> * The main patch is >>> >>> diff-merges: implement [no-]hide option and log.diffMergesHide config >>> >>> which gives us a way to redefine "-m" as "--diff-merges=hide >>> --diff-merges=on". However, we haven't seen any compelling reasons to >>> use --diff-merges=hide [1]. > > I think --diff-merges should be complete and be able to provide exact "-m" > behavior, rendering the latter pure shortcut. > > Complete orthogonal interfaces are good thing by themselves, and useful > applications of them are often found later. That's common knowledge. For the user who wants it, yes, but these interfaces come with a maintenance cost and a cost to the user who just wants the simpler interface. I think that our goals here are actually the same: we both want Git to be as simple and usable as possible. We disagree on whether this series makes Git simpler or more complex (and I don't think either of us will change our minds any time soon), but I think we can agree on an overall direction. With that in mind, I'd be willing to discuss other approaches that get us closer to "-m implies -p", if you have any. >>> I'm also fairly convinced that if we go >>> back in time, "-m" wouldn't have the semantics of 'do nothing unless >>> -p is also given', and I don't think we should immortalize a mistake >>> by giving it an explicit option. > > Yep, and I provided a config option that fixes this mistake. What's > wrong about it? The complete orthogonal interface finalized by the > aforementioned feature allows me to achieve this goal easily. Addressed above.
