[BUG] 'git log --quiet' doesn't suppress the output

The --quiet switch to 'git log' doesn't suppress the output. It only does the same as --exit-code.

Tested with version 1.6.1.2.

James

On Wed, Feb 04, 2009 at 07:19:28PM -0700, James Pickens wrote:

It suppresses the diff output (which is why it supports --quiet at all: it is a diff option). So

  git log -p --quiet

looks just like

  git log

making it largely pointless.

It would probably be trivial to for "git log" to see that the quiet switch was given and silence the commit output. But I am having trouble envisioning exactly what that would be useful for (except for being a slower version of "cat /dev/null"). Care to elaborate?

-Peff

On Fri, Feb 6, 2009 at 12:11 PM, Jeff King <peff@peff.net> wrote:

I was writing a script, and looking for a way to figure out whether there were any commits in origin/master that aren't in master (i.e., whether I need to pull before I can push), and 'git log --quiet origin/master..master' was the first thing I thought of.

James

On Fri, Feb 06, 2009 at 11:44:59PM -0700, James Pickens wrote:

OK, that does make sense.

In this case, though, you should be using the "git rev-list" plumbing instead of the "git log" porcelain for a script. And "git rev-list" does support "--quiet", but it doesn't quite do what you want. It silences the output, but the exit code does not depend on whether or not there were any commits in range.

So you would need a patch for rev-list to support --exit-code to mean "did we see anything?".

In the past I have accomplished something similar through:

  git rev-list origin/master..master | wc -l

and checking the result for "0" (I think you could even speed things up by using "git rev-list -1", because you only care about whether there are 0 or more than 0 commits, so parsing and writing the other N is pointless).

-Peff

On Fri, Feb 6, 2009 at 11:56 PM, Jeff King <peff@peff.net> wrote:

Thanks for the tip; I'll just use rev-list and check if it gave any output.

James