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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 10, 2023, 21:47 UTC
Message-ID: <xmqqjzzo46tv.fsf@gitster.g>
In-Reply-To: <878rg5vgvc.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 17 quoted lines

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