[Myrmornis]

If you're working in a git repository then IMO the most appropriate search tool is simply `git grep`. I don't think there's any reason to use ripgrep, ag, ack etc in that situation. (Personally, if I'm working with text files, then I'm nearly always in a git repo.)

[burntsushi]

(author of ripgrep here)

Well at least one reason is because ripgrep is faster. On simple literal queries they'll have comparable speed, but beyond that, `git grep` is _a lot_ slower. Here's an example on a checkout of the Linux kernel:

    $ time rg '\w+_PM_RESUME' | wc -l
    8
    
    real    0.127
    user    0.689
    sys     0.589
    maxmem  19 MB
    faults  0
    
    $ time LC_ALL=C git grep -E '\w+_PM_RESUME' | wc -l
    8
    
    real    4.607
    user    28.059
    sys     0.442
    maxmem  63 MB
    faults  0
    
    $ time LC_ALL=en_US.UTF-8 git grep -E '\w+_PM_RESUME' | wc -l
    8
    
    real    21.651
    user    2:09.54
    sys     0.413
    maxmem  64 MB
    faults  0

ripgrep supports Unicode by default, so it's actually comparable to the LC_ALL=en_US.UTF-8 variant.

There are other reasons. It is nice to use a single tool for searching in all circumstances. ripgrep can fit that role. Maybe you don't know, but ripgrep respects your .gitignore file.

[Myrmornis]

Thanks! I knew ripgrep was praised in particular for its performance but I didn't know the difference was that large. The repo I usually work in has 8.7M lines of code and I had been finding `git grep` performance very adequate (I use it in combination with the Emacs helm library where it forms part of an incremental search UI, and hence gets called multiple times in quick succession in response to changing search input.) It looks like it will be fun to try swapping in ripgrep as the helm search backend; I'll try it.