feat(scan): add [scan] dirs to set scan roots without implying home - #130
Merged
Conversation
[scan] extra always adds to home, with no way to scan only a subset of it. [scan] dirs is an exhaustive list instead: home is scanned only if it's listed. Positional CLI overrides both; dirs wins over extra if both are set, with a warning; all-missing dirs is an error rather than a silent no-op scan. Closes #129.
The path cache outlives a config change, so a cache built from a full home scan must be filtered on read rather than re-excluded wholesale when the scan roots narrow.
|
Proposal with backward-compatibility sounds perfect. Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #129.
[scan] extraonly ever adds to the home directory, so there was no way to scan a subset of home without also walking all of it. This adds[scan] dirs, an exhaustive list of scan roots where home is scanned only if you list it:This is option 1 from the issue's "alternatives considered". The reporter also suggested renaming the existing keys to drop the "extra" concept, but that breaks every existing config for a problem a second key solves cleanly, so
[scan] extrakeeps its current additive meaning and is untouched.Behaviour
dirswins overextra; setting both warns rather than silently dropping one, since they answer different questions and mixing them is almost certainly a mistake.extra(an unmounted volume shouldn't fail a run). But if every listed directory is missing, that exits 1 rather than scanning nothing at all, which would otherwise look like a successful no-op.findtraversal,mdfind -onlyin, and the path cache's in-scope filter) already keys offASIMOV_SCAN_DIRS, so narrowing the roots narrows all three. A cache left over from a full-home scan is filtered on read, not re-excluded, and out-of-scope entries stay in the file so widening the scope later brings them back.asimov doctorrecognises the new key, so a typo is still reported rather than silently ignored.Global caches under
[fixed_dirs]are still excluded regardless of scan roots, consistent with how[skip_paths]already behaves.Test plan
make checkpasses9 new Bats tests: scanning only the listed directory, multiple entries, home included only when listed explicitly, one-missing-warns, all-missing-errors,
dirsbeatingextrawith a warning, the CLI argument overridingdirs, and a cached run narrowing correctly when the roots shrink.Verified against bash 5.2 locally. Every new empty-array expansion is guarded by a count check, following the existing bash 3.2 convention in this file; the CI matrix covers 3.2 for real.
README documents the new key alongside
extrain "Scan more than your home directory".