Re: Can we clarify the purpose of `git diff -s`?

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Sergey Organov <sorganov@gmail.com> 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.

So your rationale to reject a perfectly logical behavior that *everyone* agrees
with is that it might break a hypothetical patch?

Just do `--silent` instead.

> 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,

Nothing is broken.

And we never apologized for choosing the wrong default in `git pull`, did we?

> based on what we documented and prepare a smooth transition for them.

The transition is easy: just use `--silent` instead of `--no-patch`.

We could add a warning that these semantics will change in the future, instead
of just changing it right away.

But I bet very few people will see that warning (if any), because it makes
little sense to use `--no-patch` to turn off something other than `--patch`.

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

Users can rely on what you call "bugs".

It's still a backwards-incompatible change for which you did not provide a
transitioning plan in [1].

Or is it a backwards-incompatible change *only* if the person proposing the
patch is somebody else other than the maintainer?

[1] https://lore.kernel.org/git/20230505165952.335256-1-gitster@pobox.com/

-- 
Felipe Contreras