Re: I think git show is broken

[Jeff King <peff@peff.net>]

On Tue, Aug 28, 2012 at 03:36:26PM -0700, Junio C Hamano wrote:

> > As a result, the flag would have no effect in "git log -p
> > --quiet" or "git show --quiet".  Fix it by setting the
> > format flag before the call to setup_revisions.
> 
> This also means that
> 
> 	git show --name-status --quiet
> 
> will start erroring out, if I am not recalling what diff_setup_done()
> does.  Which pretty much means "--quiet" given to the "log" family
> is truly a synonym to "-s", as the error condition that triggers is
> exactly the same for this:
> 
> 	git show --name-status -s
> 
> which is fine, I think.

Yes, I noticed that. I think it is fine for "--quiet" to be a true
synonym for "-s" here.

Though I am puzzled why we would error out on "--name-status -s" but not
"--patch -s". What is the difference between "--name-status" and
"--patch" here? Shouldn't "-s" override all formatting options?

And one final thing I noticed that is probably not worth the trouble to
fix: the position of "-s" is independent of its effect. Normally options
which override each other would be position dependent, so:

  git log --relative-date --date=local

and

  git log --date=local --relative-date

would both throw away the first option and let the latter take effect.
But doing:

  git log --patch -s

and

  git log -s --patch

will always have "-s" take over. I don't think it's a huge deal, and
fixing it would be a pain. We'd have to take NO_OUTPUT out of the
bit-field and make it a special option, and fix any callers who try to
be clever about recognizing NO_OUTPUT as a specifically-given option.
And then for "--quiet", we'd have to handle it at its proper spot on the
command-line, which would mean converting log's parse-options invocation
to be step-wise. Probably not worth it for a minor bit of consistency
that nobody has actually complained about.

-Peff