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

Glen Choo [off-list ref] writes:

quoted

Finally, event without "log.diffMerges-m-imply-p", the rest of the
series still makes sense, so if the conclusion is to remove it, let's
still merge the rest, please! Let me know, and I'll then remove the
patch and will change documentation accordingly.

Oops. Sorry, I missed this the first time I read this message. This
alone should have warranted a response.

Hmph.  I agreed with you that the last step to add the configuration
would not make sense unless we are planning to break users later,
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-<.

I'm not convinced that the series makes sense without
"log.diffMerges-m-imply-p":

* The main patch is

    diff-merges: implement [no-]hide option and log.diffMergesHide config

  which gives us a way to redefine "-m" as "--diff-merges=hide
  --diff-merges=on". However, we haven't seen any compelling reasons to
  use --diff-merges=hide [1]. I'm also fairly convinced that if we go
  back in time, "-m" wouldn't have the semantics of 'do nothing unless
  -p is also given', and I don't think we should immortalize a mistake
  by giving it an explicit option.

  All the other patches in their current form are dependent on this
  patch going in.

* diff-merges: support list of values for --diff-merges

  This only makes sense if we want to accept multiple values, which we
  don't without the main patch.

Now you mention it (and show example in the previous bullet point),
I have to agree that we would not want this, not because we do not
want to have --diff-merges with multiple values, but because it
introduces an odd-man-out option that is not "last one wins" that is
not used anywhere else in the UI.

No response does not necessarily mean an agreement, but it indeed
helped in this case to be explicit.

Thanks for the clarification.