Feature request
Two related freshness upgrades (the sibling prevention items to bug #1191's detection fix):
-
Populate the file_hashes.sha256 column. It exists in the schema but is written as "" on every path (pipeline.c persist + pipeline_incremental.c), so change detection is mtime+size only. (size, mtime) as a cheap pre-filter → sha256 confirm on mismatch keeps indexing fast while catching checkout/rsync/tar flows that preserve timestamps.
-
Filesystem-event watcher (FSEvents/inotify) instead of — or ahead of — git-status polling, so (a) non-git directories refresh at all (today watcher.c early-returns for !is_git), and (b) git pull/checkout/merge are caught immediately rather than on the next poll.
Evidence this is the industry-converged design
Surveyed 10 comparable code-graph tools: five independent implementations (in TS, Rust, and Python) converged on exactly this pair — fs events + content-hash confirm, "never git" as ground truth. One documents the rationale crisply: filesystem-based detection "works in non-git projects and catches git pull/checkout/merge that git status cannot see." The macOS-cheap variant is a single recursive FSEvents stream (O(1) fds); Linux per-directory inotify.
Practical notes from the same survey worth stealing wholesale: adaptive debounce (300ms single-save, ~2s bursts), a pending-count ceiling above which the watcher falls back to a full scan-diff (self-heals dropped events), and fail-loud degradation — after N failures, disable auto-sync and surface an actionable reason instead of going silently stale.
Happy to link the specific implementations if useful.
Feature request
Two related freshness upgrades (the sibling prevention items to bug #1191's detection fix):
Populate the
file_hashes.sha256column. It exists in the schema but is written as""on every path (pipeline.cpersist +pipeline_incremental.c), so change detection is mtime+size only.(size, mtime)as a cheap pre-filter → sha256 confirm on mismatch keeps indexing fast while catching checkout/rsync/tar flows that preserve timestamps.Filesystem-event watcher (FSEvents/inotify) instead of — or ahead of — git-status polling, so (a) non-git directories refresh at all (today
watcher.cearly-returns for!is_git), and (b)git pull/checkout/mergeare caught immediately rather than on the next poll.Evidence this is the industry-converged design
Surveyed 10 comparable code-graph tools: five independent implementations (in TS, Rust, and Python) converged on exactly this pair — fs events + content-hash confirm, "never git" as ground truth. One documents the rationale crisply: filesystem-based detection "works in non-git projects and catches git pull/checkout/merge that git status cannot see." The macOS-cheap variant is a single recursive FSEvents stream (O(1) fds); Linux per-directory inotify.
Practical notes from the same survey worth stealing wholesale: adaptive debounce (300ms single-save, ~2s bursts), a pending-count ceiling above which the watcher falls back to a full scan-diff (self-heals dropped events), and fail-loud degradation — after N failures, disable auto-sync and surface an actionable reason instead of going silently stale.
Happy to link the specific implementations if useful.