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

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

[James Pickens]

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

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

[Jeff King]

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

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

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

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

[James Pickens]

On Fri, Feb 6, 2009 at 12:11 PM, Jeff King <peff@peff.net> wrote:
> 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?

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

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

[Jeff King]

On Fri, Feb 06, 2009 at 11:44:59PM -0700, James Pickens 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.

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

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

[James Pickens]

On Fri, Feb 6, 2009 at 11:56 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Feb 06, 2009 at 11:44:59PM -0700, James Pickens 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.
>
> 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.

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

James