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.

On Jan 9, 2011, at 4:17 PM, Ævar Arnfjörð Bjarmason wrote:

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.

The plan for ack 2.0 is to have plugins that anyone can write to allow acking for whatever you want.  You'll write a plugin for PDF files and go acking for text in there, or an Excel file, or some file that specifies a Postgresql table, or whatever.  It's up to the plugin to figure out how that happens.  I'm not interested in writing hooks to git or any file system any more complicated than straight calls to open(), but plugin writers will have the flexibility to do it themselves.

xoa

--
Andy Lester => andy@petdance.com => www.techworklove.com => AIM:petdance