Sergey Organov <sorganov@xxxxxxxxx> 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".
