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

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

[Anthony Sottile]

Previously, `-q` was silently ignored:

Before:

$ git diff -q -- Documentation/; echo $?
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index a88c767..aa6e724 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -587,6 +587,7 @@ ifndef::git-log[]
        That is, it exits with 1 if there were differences and
        0 means no differences.

+-q::
 --quiet::
        Disable all output of the program. Implies `--exit-code`.
 endif::git-log[]
0
$

After:
$ ./git diff -q -- Documentation/; echo $?
1
$

Signed-off-by: Anthony Sottile <asottile@umich.edu>
---
 Documentation/diff-options.txt | 1 +
 diff.c                         | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index a88c767..aa6e724 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -587,6 +587,7 @@ ifndef::git-log[]
 	That is, it exits with 1 if there were differences and
 	0 means no differences.
 
+-q::
 --quiet::
 	Disable all output of the program. Implies `--exit-code`.
 endif::git-log[]
diff --git a/diff.c b/diff.c
index 69f0357..13dfc3e 100644
--- a/diff.c
+++ b/diff.c
@@ -4751,7 +4751,7 @@ int diff_opt_parse(struct diff_options *options,
 	}
 	else if (!strcmp(arg, "--exit-code"))
 		DIFF_OPT_SET(options, EXIT_WITH_STATUS);
-	else if (!strcmp(arg, "--quiet"))
+	else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
 		DIFF_OPT_SET(options, QUICK);
 	else if (!strcmp(arg, "--ext-diff"))
 		DIFF_OPT_SET(options, ALLOW_EXTERNAL);
-- 
2.7.4

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

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

[Junio C Hamano]

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.

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 Sat, Oct 14, 2017 at 11:37:28AM +0900, Junio C Hamano wrote:

> 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