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

Junio C Hamano wrote:

Matthieu Moy [off-list ref] writes:

quoted

https://public-inbox.org/git/51E3DC47.70107@googlemail.com/

Essentially, Stefan Beller was using 'git show --format="%ad"' and
expecting it to show only the author date, and for merge commits it
also showed the patch (--cc). I suggested -s and noticed that the
option wasn't easily discoverable, hence the patch series to better
document it and add --no-patch as a synonym.

Probably I did not get all the subtleties of the different kinds of
outputs. I guess I considered the output of diff to be the one
specified by --format plus the patch (not considering --raw, --stat &
friends), hence "get only the output specified by --format" and
"disable the patch" were synonym to me.

Thanks for double checking.  It matches my recollection that we (you
the author and other reviewers as well) added "--no-patch" back then
to mean "no output from diff machinery, exactly the same as '-s' but
use a name that is more discoverable".

quoted

Looking more closely, it's
rather clear to me they are not, and that

  git show --raw --patch --no-patch

should be equivalent to

  git show --raw

Yeah.  If this were 10 years ago and we were designing from scratch,
the "no output from diff machinery, more discoverable alias for
'-s'" would have been "--silent" or "--squelch" and we would made
any "--no-<format>" to defeat only "--<format>".

It is a different matter if we can safely change what "--no-patch"
means _now_.

We can. As we have been able to do backwards-incompatible changes in the past,
will keep doing in the future.

You yourself proposed a backwards-incompatible change here [1].

Given that "--no-patch" was introduced for the explicit purpose of giving
"-s" a name that is easier to remember, and given that in the 10 years since
we did so, we may have acquired at least a few more end users of Git than we
used to have, hopefully your change have helped them discover and learn to
use "--no-patch" to defeat any "--<format>" they gave earlier as initial
options in their script, which will be broken and need to be updated to use a
much less discoverable "-s".

That is not true.

`--no-patch` is not used to defeat any `--<format>`, it's used to disable
output, for example this:

  git show --no-patch

There is zero point in writing:

  git show --patch --no-patch

Because `--patch` is already the default.

But all of these would keep working fine if we change the semantics of
`--no-patch`.

It's not true that they will be broken.

It's only when the default is a format other than patch, or a format other than
patch is explicitely specified, for example:

  git diff-files --no-patch
  git show --raw --no-patch

Potentially the number of users who actually do this is *zero*.

A few users for some reason may have come to rely on the above behavior, but a
few users might have come to rely on the following behavior as well:

  git show -s --raw

Which your patch [1] breaks.

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

-- 
Felipe Contreras