Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > Junio C Hamano wrote: > >> Felipe Contreras <felipe.contreras@xxxxxxxxx> 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@xxxxxxxxx/ ==== 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@xxxxxxxxx/ [2] https://lore.kernel.org/git/645ea15eca6fa_21989f294f5@chronos.notmuch/ -- Felipe Contreras
