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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jan 9, 2011, 22:17 UTC
Message-ID: <AANLkTi=E0x55-RUz5CJXL_LJ6hPr--Nupp-Ti72kpNv=@mail.gmail.com>

On Sun, Jan 9, 2011 at 18:17, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:

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

Show 12 quoted lines

> * Aaron Crane <perl@aaroncrane.co.uk> [2011-01-09 13:10]:
>> 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.