git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 12, 2023, 19:47 UTC
Message-ID
<645e97da9d11e_21989f2945d@chronos.notmuch>
In-Reply-To
<87h6shif6q.fsf@osv.gnss.ru>
Sergey Organov wrote:
Show 28 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Matthieu Moy <Matthieu.Moy@univ-lyon1.fr> writes:
> >
> >> 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.
> 
> So --no-patch, if it were made to disable only --patch from the
> beginning, would still serve the purpose of solving of the original
> problem, right? Please notice that --cc produces no output without
> --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.
Indeed.
Show 32 quoted lines
> > 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".
> >
> >> 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_.  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".
> 
> Fortunately, whoever used --no-patch are very unlikely to actually rely
> on it being a synonym for "-s", as it was always enough for them that
> --no-patch disables --patch, that will still hold after the fix.
That's right.

And let's be realistic for a moment: nobody actually does `git diff-files --raw`, as that's essentially the same as `cat /dev/null`: a no-op.

The reason `--no-patch` was added was to silenced the diff output of commands that show a diff *in addition* to something else by default, like `git show`, and `git show --no-patch` will keep working fine.

Why would anybody do `git show --raw --no-patch` when they can do `git show --no-patch`?

Yet once again we are doing premature defense for a set of users that probably don't even exist.

> Finally, this safety concern is even less attractive provided recent
> "-s" fix changed behavior more aggressively yet gets no such resistance.
Exactly.
---

And this is yet another example of why git's UI is stuck and cannot (and probably will never) be fixed.

Cheers.
-- 
Felipe Contreras
Previous: Sergey OrganovNext: Felipe Contreras
Message 37 of 39 in “Can we clarify the purpose of `git diff -s`?”
  1. Felipe ContrerasMay 11, 2023
  2. Sergey OrganovMay 11, 2023
  3. Junio C HamanoMay 11, 2023
  4. Junio C HamanoMay 11, 2023
  5. Sergey OrganovMay 11, 2023
  6. Junio C HamanoMay 11, 2023
  7. Felipe ContrerasMay 11, 2023
  8. Felipe ContrerasMay 11, 2023
  9. Felipe ContrerasMay 11, 2023
  10. Sergey OrganovMay 11, 2023
  11. Felipe ContrerasMay 11, 2023
  12. Sergey OrganovMay 11, 2023
  13. Felipe ContrerasMay 11, 2023
  14. Sergey OrganovMay 11, 2023
  15. Felipe ContrerasMay 11, 2023
  16. Sergey OrganovMay 11, 2023
  17. Felipe ContrerasMay 11, 2023
  18. Sergey OrganovMay 12, 2023
  19. Felipe ContrerasMay 12, 2023
  20. Matthieu MoyMay 12, 2023
  21. Junio C HamanoMay 12, 2023
  22. Sergey OrganovMay 12, 2023
  23. Junio C HamanoMay 12, 2023
  24. Junio C HamanoMay 12, 2023
  25. Felipe ContrerasMay 12, 2023
  26. Junio C HamanoMay 12, 2023
  27. Felipe ContrerasMay 12, 2023
  28. Junio C HamanoMay 12, 2023
  29. Junio C HamanoMay 12, 2023
  30. Felipe ContrerasMay 12, 2023
  31. Sergey OrganovMay 12, 2023
  32. Junio C HamanoMay 12, 2023
  33. Sergey OrganovMay 12, 2023
  34. Felipe ContrerasMay 12, 2023
  35. Philip OakleyMay 13, 2023
  36. Sergey OrganovMay 13, 2023
  37. Felipe ContrerasMay 12, 2023
  38. Felipe ContrerasMay 12, 2023
  39. Felipe ContrerasMay 12, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.