Hacker News Reader

Comment by nickcw | Hacker News Reader

Since practically everything I work on is in a git repository, I use git grep a lot. I haven't found it wanting in speed.

Ripgrep does have some neat advanced features though...

View on HN

One reason I still use git grep is this: I have some minified .js files in the repository, which I don't want to be included in grep results. So I mark the files as binary in gitattributes, then git grep just says "Binary file foo matches".

For ripgrep, you can achieve this via a custom ignore file, e.g., `echo '*.min.js' > .ignore`.

Another approach I've seen people take is to put `-M300` in your ripgrep config file, and then any super long lines are automatically omitted from output.

Have you considered parsing .gitattributes and offering support for reducing files marked as "binary" down to a "binary file matches" notice?

Nope. I don't think I've ever used .gitattributes. Might be a neat idea. Not sure.

I've seen the few posts deciding to use .ignore as the file name but I hope this won't be a mistake in choosing the right name without enough discussion. Even for users it's hard to figure what the file is for.

I consider .grepignore to be more comprehensible.

You can also use .rgignore.

git grep is 8 chars and rg is 2.

yes, that's the primary reason for me :)

    alias g="git grep"

Ripgrep feels a lot faster (basically instant) to me than the alternatives. Even on very large repositories.

That's why I've switched to using it pretty exclusively now.

Git grep feels pretty much instant to me. Cant really understand the need for something faster unless its for searching through data files...

git grep can be fast, depending on what you're searching for and how much you need to search. If you commonly search literals, then git grep's literal optimizations probably make it good enough for you. But increasing the pattern complexity just a bit can result in large performance cliffs. For example: (times reported after running each command a few times to account for I/O cache)

    $ git clone --depth 1 https://github.com/BurntSushi/linux
    $ cd linux
    
    $ time LC_ALL=en_US.UTF-8 git grep -E '\w+_RESUME' | wc -l
    1998
    
    real    20.616
    user    2:02.49
    sys     0.363
    maxmem  64 MB
    
    $ time rg '\w+_RESUME' | wc -l
    1998
    
    real    0.127
    user    0.673
    sys     0.617
    maxmem  26 MB

Both of these invocations are doing roughly equivalent work, including respecting gitignores. Both of them are using a Unicode aware `\w` character class. OK, so you might say you don't care about Unicode. That's fine, ripgrep is still faster by an order of magnitude:

    $ time LC_ALL=C git grep -E '\w+_RESUME' | wc -l
    1998
    
    real    4.546
    user    27.741
    sys     0.420
    maxmem  63 MB

With that said, `git grep` can now be made to use PCRE2, which gives it a significant speed boost on this workload:

    $ time LC_ALL=en_US.UTF-8 git grep -P '(*UCP)\w+_RESUME' | wc -l
    1998
    
    real    0.894
    user    5.821
    sys     0.493
    maxmem  63 MB
    
    $ time LC_ALL=C git grep -P '\w+_RESUME' | wc -l
    1998
    
    real    0.517
    user    2.962
    sys     0.596
    maxmem  59 MB

ripgrep can do the same as of this release, but faster:

    $ time rg -P '\w+_RESUME' | wc -l
    1998
    
    real    0.511
    user    4.795
    sys     0.544
    maxmem  24 MB
    
    $ time rg -P --no-pcre2-unicode '\w+_RESUME' | wc -l
    1998
    real    0.422
    user    4.119
    sys     0.479
    maxmem  24 MB

Do these performance differences matter to you? Maybe not. But you said you couldn't understand; hopefully the numbers above add some clarity. :-) On top of that, ripgrep works just as well outside of git repos, on huge log files, binary data or even in shell pipelines.

Reply on news.ycombinator.com