Re: [PATCH] diff: alias -q to --quiet

From: Jeff King <peff@peff.net>
Date: Oct 16, 2017, 21:45 UTC
Message-ID: <20171016214512.xlp4ctzo37niaarx@sigill.intra.peff.net>
In-Reply-To: <xmqq60biv4if.fsf@gitster.mtv.corp.google.com>

On Sat, Oct 14, 2017 at 11:37:28AM +0900, Junio C Hamano wrote:

Show 32 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > So there are two separate questions/tasks:
> >
> >   1. Should we remove the special handling of "-q" leftover from this
> >      deprecation? I think the answer is yes.
> >
> >   2. Should we teach the diff machinery as a whole to treat "-q" as a
> >      synonym for "--quiet".
> 
> Good questions.  And thanks for archaeology.
> 
> The topic #1 above is something that should have happened when "-q" stopped working
> as "--diff-filter=d", and we probably should have started to error
> out then, so that scripts that relied on the original behaviour
> would have been forced to update.  That did not happen which was a
> grave mistake.
> 
> By doing so, we would have made sure any script that uses "-q" died
> out, and after a while, we can talk about reusing it for other
> purposes, like the topic #2 above.
> 
> Is it worth making "-q" error out while doing #1 and keep it error
> out for a few years?  I have a feeling that the answer might be
> unfortunately yes _if_ we want to also do #2.  Even though we broke
> "-q" for the scripts who wanted to see it ignore only the removals 4
> years ago and left it broken since then.  Removals are much rarer
> than modifications and additions, so it wouldn't be surprising if
> the users of these scripts simply did not notice the old breakage,
> but if we made "-q" to mean "--quiet" without doing #1, they will
> break, as all diffs these scripts work on will suddenly give an
> empty output.

Yeah, after thinking about it, I do think we'd want to restart the deprecation period. For some features it would be fine, but this one is sufficiently subtle that I agree there's a good chance scripts might have been broken without anybody noticing them.

> If we aren't doing #2, then I do not think we need to make "-q"
> error out when we do #1, though.

I don't think we'd add an explicit error-out. But by removing the leftover code, we would naturally say "no such option: -q", which amounts to the same thing.

> In any case, if we were to do both of the above two, they must
> happen in that order, not the other way around.

Yep, agreed.

-Peff