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

[Junio C Hamano <gitster@pobox.com>]

Sergey Organov <sorganov@gmail.com> writes:

> 1. The fact that -m does not imply -p is a mistake. There is no any
>    reasons this exact behavior could be useful. As such, it does not
>    make sense to support this exact behavior in --diff-merges. So the
>    reject of --diff-merges=[no-]hide.
>
> 2. This mistake is too dangerous to fix due to subtle compatibility
>    problems, so we can't just fix -m behavior. Thus the reject of my
>    earlier patch "let -m imply -p".
>
> 3. Moving behavior change under option is not worth it, as nobody
>    presumably needs this fixed -m behavior anyway (at least among 2
>    persons that are actually opposing the changes). So the reject
>    of "add diffMerges-m-imply-p configuration option" patch.
>
> 4. Staring in the face inconsistency between -m and the rest
>    of short diff-merge options is not significant enough to reconsider
>    any of the above rejects.

I do not quite understand the last one (#4), and if I were to add my
own 4., it would be that introducing --diff-merges={kind} may have
been a mistake.  It would have been fine and better to just let
users choose from whatever set of options we support, i.e. (-c,
--cc, --remerge-diff, -m -p, -m --raw, ...).

IOW, perhaps deprecate --diff-merges={kind} and eventually remove
it, if we could.  We've been fine without it and we'll be fine
without it.  Unfortunately it may be a bit too late for that,
but it certainly is much younger than "-m".