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

From: Sergey Organov <sorganov@gmail.com>
Date: May 12, 2023, 21:41 UTC
Message-ID: <877ctdi5wp.fsf@osv.gnss.ru>
In-Reply-To: <xmqq1qjlp98j.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 6 quoted lines

> 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,

Sorry, do you actually expect there is anybody here who disagrees that --no-patch logical behavior is to disable --patch? I thought you, in particular, have already agreed it's exactly "perfectly logical behavior". So there are at least 3 of us who explicitly agreed it is, and nobody who stated his disagreement. No?

Show 6 quoted lines

> and as we all saw in public some members stated they will not engage
> in a discussion thread in which you were involved. In addition, at PLC
> I've seen people complain about how quickly a discussion that involves
> you becomes unproductive---they may have better sence of backward
> compatibility concern than you two, but they are staying silent (they
> are wiser than I am).

The above statement with the word "everyone" was not about backward compatibility, where we obviously expect different opinions from different people.

As for the sense, maybe there are people out there who do have better sense indeed, but then maybe some of them keep silence out of agreement? For what it's worth, @work I do have to maintain CI that is 600-pages long document and to take care of backward compatibility, so I do have at least some experience in this field beyond Git, and I do sympathize the conservatism in this field, and only argue about practical thresholds.

As for backward compatibility itself, what I see as a problem is that the criteria of when backward incompatibility is to be considered a show-stopper, and when not, are unclear and look entirely voluntary from here. At least I was not able to correctly predict the outcome so far, that is rather discouraging.

[...]

> I am *not* shutting the door for "--no-patch";

That apparently confirms that you still do consider it "the perfectly logical behavior".

> I am only saying that it shouldn't be done so hastily.

I won't even try to insist on immediate fix, though I still don't see why shouldn't we just do it while we are at the issue, and be done with it.

> Indeed "--silent" or "--squelch" is one of the things that I plan to
> suggest when we were to go with "--no-patch is no longer -s" topic.

While we are at this, may I vote against "--squelch", please? For me it'd be undiscoverable, as it's the first time I ever hear this word in such context. Moreover, from the meaning of the word I'd expect it to silence output unless the size of diff exceeds some limit, that in turn makes little sense. Or maybe it makes some sense? Hmm. "Show me only diffs that are more than 10 lines long". It'd be entirely different option anyway.

Thanks, -- Sergey Organov