4 ms·
I don't think this is the same thing as using gitignore. It will only search tracked files. For that it can just use the index. I would expect the index to be
by EnPissant 1y ago
I don't think this is the same thing as using gitignore.
It will only search tracked files. For that it can just use the index. I would expect the index to be faster than looking at the fs for listings.
- burntsushi 1y agoI was extremely careful with my wording. Re-quoting, with added emphasis: > ripgrep should generally already be approximating `git ls-files` by respecting gitignore. See also: https://news.ycombinator.com/item?id=45629515 https://news.ycombinator.com/item?id=45629515
- EnPissant 1y agoI'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 agoYes, 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.