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

From: Glen Choo <chooglen@google.com>
Date: Mar 6, 2023, 22:22 UTC
Message-ID: <kl6lzg8pcygl.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <87wn3zqefx.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 15 quoted lines

>> 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.

Show 16 quoted lines

>>> 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.

Show 8 quoted lines

>>> 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.