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

Ævar Arnfjörð Bjarmason· Jan 9, 2011, 22:17 UTC · lore

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.

Andy Lester· Jan 10, 2011, 03:38 UTC · re: Ævar Arnfjörð Bjarmason · lore

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

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