{"thread":{"id":"26247","subject":"Maybe there should be a git-grep plumbing interface for ack et al.","startedAt":"2011-01-09T22:17:09Z","lastAt":"2011-01-10T03:38:14Z","messageCount":2,"participants":["Ævar Arnfjörð Bjarmason","Andy Lester"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159256","messageId":"AANLkTi=E0x55-RUz5CJXL_LJ6hPr--Nupp-Ti72kpNv=@mail.gmail.com","threadId":"26247","inReplyTo":null,"subject":"Maybe there should be a git-grep plumbing interface for ack et al.","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-01-09T22:17:09Z","receivedAt":"2011-01-09T22:17:09Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Jan 9, 2011 at 18:17, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:\n\n[CC'd Andy & the Git list in case they're interested]\n\n> * Aaron Crane <perl@aaroncrane.co.uk> [2011-01-09 13:10]:\n>> AFAICT, the most important reason for the speed of `git grep`\n>> is that (in recent versions, at least) it uses multiple\n>> threads. […] I believe that ability should be reasonably easy\n>> to reimplement in a Perl grep-a-like\n>\n> I assumed, on no factual basis, that one of the reasons is that\n> it uses the object store whenever possible instead of the working\n> copy, which would speed up `git grep` in much the same way it\n> makes `git checkout` faster than `cp -R`. (Compression and linear\n> pack files reduce I/O.) I don’t know if that’s actually the case,\n> though. But such an avenue is not open to generic grep clones.\n\nYes, this is correct. git-grep(1) is fast because it doesn't have to\ndo the I/O that grep(1) and ack(1) have to do. It can just read the\ngit tree/object files.\n\nIncidentally (since I also work on git.git) one idea for a project I\nhad was to add a new plumbing command that does the grep-like things\ngit-grep(1) does but allow someone to implement their own\ngrep-er. I.e. just spew out filename/line pairs on stdout.\n\nThen e.g. ack(1) could use this new plumbing command to read files\nwhen in a git repository, but could provide Perl's regex features and\nother things it has.\n\nBut last I looked Ack was fairly unmodularized, so adding that sort of\nstuff might be hard. But that might have changed.\n"},{"id":"159258","messageId":"A206547D-A7FF-49CD-A122-0FDCD2FBF452@petdance.com","threadId":"26247","inReplyTo":"AANLkTi=E0x55-RUz5CJXL_LJ6hPr--Nupp-Ti72kpNv=@mail.gmail.com","subject":"Re: Maybe there should be a git-grep plumbing interface for ack et al.","fromName":"Andy Lester","fromEmail":"andy@petdance.com","sentAt":"2011-01-10T03:38:14Z","receivedAt":"2011-01-10T03:38:14Z","isPatch":false,"sender":{"key":"andy@petdance.com","avatar":"https://gravatar.com/avatar/997ccaea115635c2be5051f455bbe6287c0f13aa59c96e1d6eb21ba3589239fb?d=mp&s=160"},"body":"\nOn Jan 9, 2011, at 4:17 PM, Ævar Arnfjörð Bjarmason wrote:\n\n> Then e.g. ack(1) could use this new plumbing command to read files\n> when in a git repository, but could provide Perl's regex features and\n> other things it has.\n\nThe 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.\n\nxoa\n\n--\nAndy Lester => andy@petdance.com => www.techworklove.com => AIM:petdance\n"}]}