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

[Felipe Contreras <felipe.contreras@gmail.com>]

Sergey Organov wrote:
> 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.

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

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