mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 00:02:23 +00:00
l0ng-ai
212d5110ef
With a repository open, an idle window ran `git status -uall` about 2.6 times a second, forever. Measured on the Linux CI runner: 78 debounce bursts in 30 seconds, from one real change. `notify`'s inotify backend subscribes with `WatchMask::OPEN`, so every `open(2)` under a watched directory is an event. `git status` opens `.git/index`, `.git/HEAD` and `refs/heads/*`, all of which the source control watch covers — so the read that answers "did this repository change" is itself an event saying it may have changed, and the answer schedules the next question. The debounce caps the rate; it cannot break the cycle. `Debounce`'s own doc argued this was structurally impossible, because `GIT_OPTIONAL_LOCKS=0` stops `git status` writing the index back. That covers writes. `IN_OPEN` fires on reads, and no environment variable suppresses it. macOS FSEvents has no equivalent, so this was invisible on the machine it was written on, and every theory that did not involve the kernel was correctly eliminated before this one was found. `is_content_change` drops `Access(Open | Read | Close(Read))` and keeps `Access(Close(Write))`, which is a write finishing rather than a reader. Applied at both watchers: the host watch, and the config hot-reload watch in `main.rs`, which has the same shape — a reload re-reads the file it is watching. The guard is a host conformance case rather than a platform test, because macOS passes it trivially and Linux is where it has to hold. It was verified red on the Linux runner with the filter removed. Its drain waits out the create of the file it asserts about: FSEvents hands that over a beat after the stream opens, and a stale create is indistinguishable here from a read reporting.