I was extremely careful with my wording. Re-quoting, with added emphasis:

> ripgrep should generally already be approximating `git ls-files` by respecting gitignore.

▲ EnPissant 2 days ago | parent [-]

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 2 days ago \| parent [-]
		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.