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

[Jeff King]

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

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

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

[Junio C Hamano]

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

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

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

Thanks.

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

[Jeff King]

On Fri, Oct 13, 2017 at 09:44:15AM -0700, Anthony Sottile wrote:

> Previously, `-q` was silently ignored:

I'm not sure if is totally ignored. Normally if we have an unknown
options we'd complain:

  $ git diff -x
  error: invalid option: -x

but we don't with "-q". Why?

In builtin/diff.c:471, we can see:

  else if (!strcmp(argv[1], "-q"))
  options |= DIFF_SILENT_ON_REMOVED;

So it _does_ do something, just not what you expected.

But wait, that's not the whole story. We convert "-q" into
SILENT_ON_REMOVED in git-diff-files and in git-diff (when we're acting
like diff-files). But nobody ever seems to check it!

Running "git log -p -SSILENT_ON_REMOVED" turns up two interesting
commits:

  - 95a7c546b0 (diff: deprecate -q option to diff-files, 2013-07-17)

  - c48f6816f0 (diff: remove "diff-files -q" in a version of Git in a
distant future, 2013-07-18).

So we dropped "-q" a few years ago and added a deprecation notice. "git
tag --contains 95a7c546b0" tells us that happened in v1.8.5, which
shipped in Nov 2013.

And then in v2.0.0 (May 2014) we tried to drop "-q" completely. Looking
over c48f6816f0, I _think_ it's a mistake that "-q" became a silent noop
there. That commit should have ripped out the remaining bits that set
the SILENT_ON_REMOVED flag, and "-q" would have become an error.

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

 Probably yes, but it's less clear to me that this won't have funny
 interactions. Are there other commands which use the diff-options
 parser via setup_revisions(), but expect "-q" to be left in the
 output so that they can handle it themselves?

 It looks like git-log does so, but it pulls the "-q" out before
 handing the remainder to setup_revisions(). And anyway, it just
 converts the option into a quiet diff (though it does in a way
 that's different than the rest of the diff code -- that might bear
 investigating on its own).

 Grepping for 'q' and OPT__QUIET, I don't see any others, but I
 didn't spend very much time digging.

-Peff