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
git log --date=local --relative-date
would both throw away the first option and let the latter take effect.
git log --patch -s
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html