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

[Sergey Organov <sorganov@gmail.com>]

Glen Choo <chooglen@google.com> writes:

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

We are walking in rounds here. Let me try to find at least some common
ground. Could we try to agree on *one* of these 2 mutually exclusive
statements, please:

1. Current -m behavior is useful

2. Current -m behavior is useless

To me it looks like Junio thinks 1 is the case, and you, Glen, think
it's 2 that is the case, and you both somewhat oppose to my patch
series, believing you agree with each other, that in fact does not seem
to be the case from my POV, effectively leaving me no way to adopt the
series so that they are actually accepted.

Thanks,
-- Sergey Organov