5 ms·

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

• baq 8y ago
  git grep is 8 chars and rg is 2. yes, that's the primary reason for me :)
  • rootlocus 8y ago
    alias g="git grep"
• the_duke 8y ago
  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.
  • zadler 8y ago
    Git grep feels pretty much instant to me. Cant really understand the need for something faster unless its for searching through data files...
    • burntsushi 8y ago
      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.
• bluetech 8y ago
  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".
  • burntsushi 8y ago
    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.
    • JoshTriplett 8y ago
      Have you considered parsing .gitattributes and offering support for reducing files marked as "binary" down to a "binary file matches" notice?
      • burntsushi 8y ago
        Nope. I don't think I've ever used .gitattributes. Might be a neat idea. Not sure.
    • h1d 8y ago
      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.
      • burntsushi 8y ago
        You can also use .rgignore.