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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> wrote:
>
> 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"`.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]