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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 12, 2023, 23:07 UTC
Message-ID: <645ec6c64bbd7_21cbbf294bf@chronos.notmuch>
In-Reply-To: <877ctdi5wp.fsf@osv.gnss.ru>

Sergey Organov wrote:

Show 13 quoted lines

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

Matthieu Moy as well, so it's 4 versus 0.

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

I do have experience as well, as I was the one who proposed the preventive warning on changing the default of `git pull`, also changing the default of init.defaultbranch, and for the record I also warned against the move from `git-foo` to `git foo` without warning back in v1.6, which resulted in a debacle.

If anything I would argue I've been more conscious of breaking backwards-compatibility for *actual* git users.

This is an ad hominem red herring.

Show 10 quoted lines

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

I as well.

I could write yet another patch that throws a warning about a future change instead of doing the change.

But I'm reasonably certain Junio will ignore that proposal as well.

Show 6 quoted lines

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

Also agree. I've never heard the word "squelch" outside of the git context, and I'm pretty sure my English vocabulary is not small. Multiple people have suggested "silent" and no one has suggested "squelch" (other than Junio).

Cheers.

-- 
Felipe Contreras