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

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

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > Junio C Hamano wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> 
> >> > So your rationale to reject a perfectly logical behavior that *everyone* agrees
> >> > with is that it might break a hypothetical patch?
> >> 
> >> Everyone is an overstatement, as there are only Sergey and you,
> >
> > Matthieu Moy also agreed [1]:
> >
> >   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
> >
> > That's pretty much everyone that has participated in the discussion.
> >
> >> and as we all saw in public some members stated they will not engage in a
> >> discussion thread in which you were involved.
> >
> > Smoke screen.
> >
> >> > Just do `--silent` instead.
> >> 
> >> I am *not* shutting the door for "--no-patch"; I am only saying that
> >> it shouldn't be done so hastily.
> >
> >> But conflating the two will delay the fix for "-s sticks unnecessarily" that
> >> is ready for this cycle.
> >
> > That breaks backwards-compatibility.
> >
> > Why are your patches excempt from bacwards-compatibility considerations?
> 
> It is not who wrote the patch.
> 
> You either did not read what I wrote earlier in the thread
> 
>     ... 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.
> 
> or you are trying to paint a picture that is different from reality
> with whatever motive you have.

I replied to that comment quoting it in full [2]:

====
  > 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/
====

How can I paint a picture different from reality when I'm quoting exactly what
you said?

> Either way, I am not done with the thread, as I said.

You can say you are done with the thread, but your change [1] still breaks
backwards compatibility.

Does your patch change the behavior of this command?

  git show -s --raw

The answer is a "yes" or a "no". Personal attacks are not a valid answer.

[1] https://lore.kernel.org/git/20230505165952.335256-1-gitster@pobox.com/
[2] https://lore.kernel.org/git/645ea15eca6fa_21989f294f5@chronos.notmuch/

-- 
Felipe Contreras