Re: Can we clarify the purpose of `git diff -s`?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 12, 2023, 21:47 UTC
- Message-ID
- <xmqqlehtnrw4.fsf@gitster.g>
- In-Reply-To
- <645ea94569b79_21b4f8294e7@chronos.notmuch>
Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 36 quoted lines
> 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. Either way, I am not done with the thread, as I said.