Re: so/diff-merges-more (was Re: What's cooking in git.git (Feb 2023, #01; Thu, 2))

[Glen Choo <chooglen@google.com>]

Sergey Organov <sorganov@gmail.com> 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.