Maybe there should be a git-grep plumbing interface for ack et al.

On Sun, Jan 9, 2011 at 18:17, Aristotle Pagaltzis [off-list ref] wrote:

[CC'd Andy & the Git list in case they're interested]

* Aaron Crane [off-list ref] [2011-01-09 13:10]:

quoted

AFAICT, the most important reason for the speed of `git grep`
is that (in recent versions, at least) it uses multiple
threads. […] I believe that ability should be reasonably easy
to reimplement in a Perl grep-a-like

I assumed, on no factual basis, that one of the reasons is that
it uses the object store whenever possible instead of the working
copy, which would speed up `git grep` in much the same way it
makes `git checkout` faster than `cp -R`. (Compression and linear
pack files reduce I/O.) I don’t know if that’s actually the case,
though. But such an avenue is not open to generic grep clones.

Yes, this is correct. git-grep(1) is fast because it doesn't have to
do the I/O that grep(1) and ack(1) have to do. It can just read the
git tree/object files.

Incidentally (since I also work on git.git) one idea for a project I
had was to add a new plumbing command that does the grep-like things
git-grep(1) does but allow someone to implement their own
grep-er. I.e. just spew out filename/line pairs on stdout.

Then e.g. ack(1) could use this new plumbing command to read files
when in a git repository, but could provide Perl's regex features and
other things it has.

But last I looked Ack was fairly unmodularized, so adding that sort of
stuff might be hard. But that might have changed.