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

From: Jeff King <peff@peff.net>
Date: Feb 7, 2009, 06:56 UTC
Message-ID: <20090207065602.GA14995@coredump.intra.peff.net>
In-Reply-To: <885649360902062244v715a61b7nf32003c97cc4f707@mail.gmail.com>

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

Show 5 quoted lines

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

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