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

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