Re: Make "git log --count" work like "git rev-list"

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 9, 2019, 17:44 UTC
Message-ID: <CAHk-=wjip45uqONG=Qzevd0HoT47t7NatSpr+N3ifMZehr2M0Q@mail.gmail.com>
In-Reply-To: <CAGZ79kaOcoVSRgTR+k9ENoDz6FHh27MzpZ9D-MeFArN2vgBK0w@mail.gmail.com>

On Wed, Jan 9, 2019 at 9:21 AM Stefan Beller <sbeller@google.com> wrote:

Show 8 quoted lines

>
> Sounds reasonable to me to have such functionality,
> as I tend to use
>   git log --oneline origin/master..origin/next --no-merges |wc -l
> for such queries, which I always assume to be doing useless
> work as I'd be interested in *only* the count, and not the
> intermediate oneline output, but that is the best output
> that wc works on.

Right. I've been known to do that too, but because I grew up with "git rev-list", I know about --count and tend to use it.

In fact, I've occasionally used it with "git log" already (before my patch), and it would silently accept the parameter (because it's parsed by the generic revision parsing), it just wouldn't work.

> So maybe the --count option would want to suppress
> other output if given (or we'd want to have another option
> for no output)?

It already does so in my patch, exactly because it uses the same logic as "git rev-list --count" does.

Which is to simply react to the "--count" thing early in log_tree_commit(), and do the counting and then say "I showed this" (without showing anything).

So you can do silly things like this:

    [torvalds@i7 linux]$ git log --count -10
    10
    [torvalds@i7 linux]$

and it just works. Nonsensical, but logical.

              Linus