Re: [PATCH] fsmonitor: invalidate untracked cache after losing history

> From: Derrick Stolee <stolee@gmail.com>
>
> When fsmonitor fails or returns a trivial response, refresh_fsmonitor()
> clears CE_FSMONITOR_VALID and disables fsmonitor use for the untracked
> cache. Unfortunately, this may leave untracked cache entries marked
> 'valid' so future commands may miss necessary updates.
>
> A command such as 'git update-index --refresh' can save the replacement
> fsmonitor token without scanning untracked directories. If the next
> query returns no changes, fsmonitor use is enabled again and 'git status'
> trusts directory contents cached before the loss of event history. New
> untracked files can remain invisible.
>
> This integration bug between fsmonitor and the untracked cache has
> existed since the fsmonitor feature was introduced in 883e248b8a0
> (fsmonitor: teach git to optionally utilize a file system monitor to
> speed up detecting new or changed files., 2017-09-22).
>
> To fix the problem, react more completely on a failed fsmonitor token
> request. In this case, invalidate every untracked cache directory and
> mark the untracked extension as changed. To guarantee that the index is
> updatede, set UNTRACKED_CHANGED so that the index is written even when
> no tracked entry changes. Keep the directory nodes intact to preserve
> pointers held by callers.
> ...
>     fsmonitor: invalidate untracked cache after losing history
>     
>     A user of an internal monorepo reported this behavior, including an
>     AI-assisted powershell script to prove how it worked. I used an agent to
>     assist in porting that to a Git test script and a code fix, but then
>     applied significant human editing and validation on top to get it up to
>     my standards.
>     
>     Thanks, -Stolee