From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
Matthieu Moy <Matthieu.Moy@univ-lyon1.fr>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Can we clarify the purpose of `git diff -s`?
Date: Sat, 13 May 2023 00:41:42 +0300 [thread overview]
Message-ID: <877ctdi5wp.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqq1qjlp98j.fsf@gitster.g> (Junio C. Hamano's message of "Fri, 12 May 2023 13:47:56 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> 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?
> 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
next prev parent reply other threads:[~2023-05-12 21:41 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 3:14 Can we clarify the purpose of `git diff -s`? Felipe Contreras
2023-05-11 11:59 ` Sergey Organov
2023-05-11 16:26 ` Junio C Hamano
2023-05-11 17:37 ` Junio C Hamano
2023-05-11 18:04 ` Sergey Organov
2023-05-11 18:27 ` Junio C Hamano
2023-05-11 18:36 ` Felipe Contreras
2023-05-11 18:17 ` Felipe Contreras
2023-05-11 17:41 ` Felipe Contreras
2023-05-11 18:31 ` Sergey Organov
2023-05-11 19:10 ` Felipe Contreras
2023-05-11 19:32 ` Sergey Organov
2023-05-11 19:54 ` Felipe Contreras
2023-05-11 20:24 ` Sergey Organov
2023-05-11 20:59 ` Felipe Contreras
2023-05-11 22:49 ` Sergey Organov
2023-05-11 23:28 ` Felipe Contreras
2023-05-12 8:40 ` Sergey Organov
2023-05-12 19:19 ` Felipe Contreras
[not found] ` <5bb24e0208dd4a8ca5f6697d578f3ae0@SAMBXP02.univ-lyon1.fr>
2023-05-12 8:15 ` Matthieu Moy
2023-05-12 17:03 ` Junio C Hamano
2023-05-12 18:21 ` Sergey Organov
2023-05-12 19:21 ` Junio C Hamano
2023-05-12 19:34 ` Junio C Hamano
2023-05-12 20:28 ` Felipe Contreras
2023-05-12 20:47 ` Junio C Hamano
2023-05-12 21:01 ` Felipe Contreras
2023-05-12 21:47 ` Junio C Hamano
2023-05-12 21:48 ` Junio C Hamano
2023-05-12 23:21 ` Felipe Contreras
2023-05-12 21:41 ` Sergey Organov [this message]
2023-05-12 22:17 ` Junio C Hamano
2023-05-12 22:47 ` Sergey Organov
2023-05-12 23:07 ` Felipe Contreras
2023-05-13 14:58 ` Philip Oakley
2023-05-13 17:45 ` Sergey Organov
2023-05-12 19:47 ` Felipe Contreras
2023-05-12 19:34 ` Felipe Contreras
2023-05-12 19:17 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877ctdi5wp.fsf@osv.gnss.ru \
--to=sorganov@gmail.com \
--cc=Matthieu.Moy@univ-lyon1.fr \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).