Web lists-archives.com

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




On Sat, Jan 5, 2019 at 2:47 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> This is a ridiculous patch. And I understand entirely if nobody else
> cares, because I don't think anybody else has ever even noticed.
>
> It turns out that I still use "git rev-list" outside of some hard-core
> scripting for one silly reason: the linux-next statistics are all
> about non-merge commits, and so to do a rough comparison with
> linux-next, I do
>
>         git rev-list --count --no-merges v4.20..
>
> to get an approximate idea of how much I've merged compared to what is
> in linux-next.
>
> (See also
>
>         http://neuling.org/linux-next-size.html
>
> for the graphical view of it all, even though it looks a bit odd right
> now because of how linux-next wasn't being updated over the holidats
> and right at the 4.19 release).
>
> Anyway, I've occasionally thought to myself that I should just fix
> "git log" to learn that too, so that I wouldn't have to type out "git
> rev-list". Because "git log" does actually take the "--count"
> argument, it just doesn't honor it.
>
> This is that patch.

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.

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

Instead of printing, do we want to redirect to
rev->diffopt.file, or send it through the diff codes
buffer if we ever anticipate needing this output in
buffered?

A test would be nice, too.

Stefan