mirror of
https://github.com/patriceckhart/zot.git
synced 2026-06-26 21:36:31 +02:00
1a3e0a572e
The recursive @-picker only read the repo's root .gitignore, so a nested .gitignore (e.g. .opencode/.gitignore ignoring its own node_modules) was invisible. WalkDir visits lexically, so a dot-prefixed vendored tree got walked first and its node_modules flooded the 5000-entry budget before the walk ever reached deeply nested source files. The picker then fuzzy-matched against junk and never surfaced the real target. - Add ignore.Stack: a per-directory .gitignore chain pushed/popped as the recursive walk descends, with git-style nearest-file-wins semantics including nested negations. scanRecursive now prunes nested-ignored trees like node_modules. - Raise maxRecursiveEntries 5000 -> 50000 and maxRecursiveDepth 12 -> 24. The bottleneck is per-keystroke fuzzy.Find, not memory: a fileEntry is ~120 bytes (~6 MB at 50k), and benchmarked fuzzy.Find latency is ~2ms @ 5k, ~13ms @ 50k, ~21ms @ 100k, so 50k keeps ranking under one 60Hz frame while holding a large monorepo once nested-gitignore pruning has done its job. Verified against the reporting monorepo: the fully-pruned tree is 4397 entries (node_modules=0), scan ~360ms once (cached after), match ~2.5ms per keystroke, and @pipeline.py now finds eda/rjg/enk-1150/pipeline.py. Adds regression tests at both the ignore.Stack layer and the file_suggest layer, including a repro of the nested-node_modules + deep-file scenario. |
||
|---|---|---|
| .. | ||
| gitignore.go | ||
| gitignore_test.go | ||