Re: [PATCH] --count feature for git shortlog

From: Lawrence Siebert <lawrencesiebert@gmail.com>
Date: Jul 1, 2015, 03:00 UTC
Message-ID: <CAKDoJU42kDs3QXYjo7rJ-vLMJtUdv9AwttJLHnya+toG6cSatQ@mail.gmail.com>
In-Reply-To: <CAKDoJU4cEvWvfnFsvfOJ_P0UOrD3RpLK1NdfxaUPiDTWXYg-oA@mail.gmail.com>

Vincent, I'm ccing you because of --use-bitmap-index

John, Johannes,

I really appreciate both your thoughts.

`git rev-list --count HEAD -- "$FILENAME"` runs noticeably faster then
my patch code for `git shortlog --count`, git shortlog -s "$FILENAME"
| cut -f 1 | paste -sd+ -|bc, and faster than any use of piping to wc
-l mentioned so far.  Anyway I think Junio is quite right that my code
doesn't belong in shortlog, at least as it currently is.

I have some ideas for future work for myself, both code and documentation changes. I can detail it and get comments first, or just submit patches and get comments after, whichever is the preferred practice. One in particular is worth mentioning.

The following doesn't currently run: `git rev-list --count --use-bitmap-index HEAD`

This is an optional parameter for rev-list from commit aa32939fea9c8934b41efce56015732fa12b8247 which can't currently be used because of changes in parameter parsing, but which modifies `--count` and which may be faster. I've gotten it working again, both by changing the current repo code to make it work, and also by building from that commit, and when I tested it on the whole repo, it seems like it's less variable in speed then `git rev-list --count HEAD`. but not necessarily consistently faster like tests suggested it was when it was committed. Obviously I'm not testing on the same system as the original committer, or with the same compiler, or even using the same version of the linux kernel repo, so those may be a factor. It may also work better in a circumstance that I haven't accounted for, like an older repo, on a per file basis when getting per file commit counts for all files, or something like that.

I'm thinking I could submit a patch that makes it work again, and leave it to the user to decide whether to use it or not. There is also a --test-bitmap option which compares the regular count with the bitmap count. I'm not sure if the implication there was regression testing or that --use-bitmap-index might give the wrong results in certain circumstances. Vincent, could you clarify?

Thanks, Lawrence Siebert http://www.github.com/gryftir

On Tue, Jun 30, 2015 at 5:23 AM, John Keeping <john@keeping.me.uk> wrote:

Show 16 quoted lines

>
> On Tue, Jun 30, 2015 at 02:10:49PM +0200, Johannes Schindelin wrote:
> > On 2015-06-29 18:46, Lawrence Siebert wrote:
> >
> > > I appreciate your help. Okay, That all makes sense.
> > >
> > > I would note that something like:
> > >  git shortlog -s "$FILENAME:  | cut -f 1 | paste -sd+ - | bc
> > >
> > > seems like it run much faster then:
> > >
> > >  git log --oneline "$FILENAME" | wc -l
> >
> > How does it compare to `git rev-list -- "$FILENAME" | wc -l`?
>
> Or even `git rev-list --count HEAD -- "$FILENAME"`.