Front page | perl.perl5.porters |
Postings from January 2011
Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
> I loved ack in my Subversion days, but git-grep has displaced it
> for almost all uses I had for it. Because git-grep uses the list
> of tracked files to look for candidates, it does not have to rely
> on the crutch that is file type detection. What’s more, it’s far
> faster.
AFAICT, the most important reason for the speed of `git grep` is that
(in recent versions, at least) it uses multiple threads. IIRC, there
are as many threads as CPU cores, and each file is examined in a
single thread. I believe that ability should be reasonably easy to
reimplement in a Perl grep-a-like, subject to the normal portability
constraints of choosing when to `use threads` versus simply forking
worker processes to do the matching.
> I miss ack’s grouped output layout, though.
That's not a feature I feel strongly about myself, but I dare say
hacking it into `git grep` would be reasonably easy. (Especially when
multiple files are being examined in parallel; per-file matches
already need to be batched up before any are emitted, lest matches
from distinct files get interleaved.)
> ggv() { git grep -l -E "$@" | xargs ${DISPLAY:+g}vim ; }
Given a sufficiently recent Git, that can be just
ggv() { git grep -O${DISPLAY:+g}vim -E "$@"; }
--
Aaron Crane ** http://aaroncrane.co.uk/
Thread Previous
|
Thread Next