Which fff frontend(s)?
Core or Rust crate
What problem are you trying to solve?
An option to provide scan_inclusions, namely to enable explicit inclusions of otherwise ignored paths.
This would I think be a better solve than #108/#530 (request for no-gitignore)
This basically would close #80
This is similar to #448 but it scopes the list up instead of down
The argument for scan_inclusions is that increasingly repos need to control what their agents can find, and also what can be fuzzy-found from file search UIs. It would be generally useful, and as a few examples of common cases of gitignored files that many repos would like to make easily findable: .env.local, log files, skills localed in home dir.
prior art here is zed, which supports exactly this through file_scan_inclusions setting.
I have a PR (claude) but I didnt want to open it without discussion since IANA rust dev
Proposed solution
scan_inclusions as a list of glob patterns relative to the indexed root
rt2zz@f33677a
Which fff frontend(s)?
Core or Rust crate
What problem are you trying to solve?
An option to provide scan_inclusions, namely to enable explicit inclusions of otherwise ignored paths.
This would I think be a better solve than #108/#530 (request for no-gitignore)
This basically would close #80
This is similar to #448 but it scopes the list up instead of down
The argument for scan_inclusions is that increasingly repos need to control what their agents can find, and also what can be fuzzy-found from file search UIs. It would be generally useful, and as a few examples of common cases of gitignored files that many repos would like to make easily findable: .env.local, log files, skills localed in home dir.
prior art here is zed, which supports exactly this through file_scan_inclusions setting.
I have a PR (claude) but I didnt want to open it without discussion since IANA rust dev
Proposed solution
scan_inclusions as a list of glob patterns relative to the indexed root
rt2zz@f33677a