Sergey Organov <sorganov@xxxxxxxxx> writes: > --patch. Thus, making --no-patch a synonym for -s was a mistake in the > first place that leaked through review process at that time, and > > git show --format="%ad" --no-patch > > will still work the same way even if we fix --no-patch to disable > --patch only. Not so fast. I have a show.outputFormat configuration variable to teach builtin/log.c::show_setup_revisions_tweak() to tweak the hardcoded default from DIFF_FORMAT_PATCH to others (primarily because I often find myself doing "git show -p --stat"). Changing "--no-patch" to toggle only "--patch" away will close the door for future improvement like that, and "will still work" is an illusion. The user needs to be told that "--no-patch" no longer means "-s" and somebody needs to apologize to them that we are deliberately breaking their reliance they held for 10 years, based on what we documented and prepare a smooth transition for them. Until the time when nobody uses "--no-patch" as a synonym for "-s" any longer, such a future improvement would be blocked. And that is another reason why I want to be much more careful about "should --no-patch be changed to mean something other than -s" than "should -s be fixed not to be sticky for some but not all options". The latter is not a documented "feature" and it clearly was a bug that "-s --raw" did not honor "--raw". The former was a documented "feature", even though it may have been a suboptimal one.
