4 ms·

I was extremely careful with my wording. Re-quoting, with added emphasis: > ripgrep should generally already be approximating `git ls-files` by respecting giti

• EnPissant 1y ago
  I'm just trying to be helpful, not call you out. I've implemented gitignore aware file scanning before, and it was slower than git native operations when you only care about tracked files. It's the speed that is the part I was speaking too, not the semantics.
  • burntsushi 1y ago
    Yes, I agree, `git ls-files` can indeed be faster than just `rg --files`. On my Chromium checkout: $ hyperfine --output pipe 'rg --files' 'git ls-files' Benchmark 1: rg --files Time (mean ± σ): 141.2 ms ± 7.1 ms [User: 1134.5 ms, System: 376.3 ms] Range (min … max): 128.7 ms … 154.8 ms 20 runs Benchmark 2: git ls-files Time (mean ± σ): 54.9 ms ± 1.7 ms [User: 41.7 ms, System: 13.1 ms] Range (min … max): 52.2 ms … 62.0 ms 54 runs Summary git ls-files ran 2.57 ± 0.15 times faster than rg --files But the semantics here are important, because ripgrep doesn't only try to approximate `git ls-files`. It also needs to deal with `.rgignore` and `.ignore`. And no git repository state will help there. ripgrep also supports respecting `.gitignore` even when it isn't inside a git repository.