git-for-windows/git
1
0
Fork 0
mirror of https://github.com/git-for-windows/git.git synced 2026-03-16 19:41:56 -05:00
Code Issues Packages Projects Releases 335 Wiki Activity

fsmonitor: force update index when fsmonitor token advances

Browse Source 
Set the `FSMONITOR_CHANGED` bit on `istate->cache_changed` when the
fsmonitor response contains a different token to ensure that the index
is written to disk.

Normally, when the fsmonitor response includes a tracked file, the
index is always updated.  Similarly, the index might be updated when
the response alters the untracked-cache (when enabled).  However, in
cases where neither of those cause the index to be considered changed,
the fsmonitor response is wasted.  And subsequent commands will
continue to make requests with the same token and if there have not
been any changes in the working directory, they will receive the same
response.

This was observed on Windows after a large checkout.  On Windows, the
kernel emits events for the files that are changed as they are
changed.  However, it might delay events for the containing
directories until the system is more idle (or someone scans the
directory (so it seems)).  The first status following a checkout would
get the list of files.  The subsequent status commands would get the
list of directories as the events trickled out.  But they would never
catch up because the token was not advanced because the index wasn't
updated.

This list of directories caused `wt_status_collect_untracked()` to
unnecessarily spend time actually scanning them during each command.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
This commit is contained in:
Jeff Hostetler
2021-01-07 16:45:13 -05:00
committed by Johannes Schindelin
parent 97d2536ea6
commit 3863144c8e
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
fsmonitor.c
View File

@@ -353,6 +353,16 @@ void refresh_fsmonitor(struct index_state *istate)
}
strbuf_release(&query_result);
/*
* If the fsmonitor response and the subsequent scan of the disk
* did not cause the in-memory index to be marked dirty, then force
* it so that we advance the fsmonitor token in our extension, so
* that future requests don't keep re-requesting the same range.
*/
if (istate->fsmonitor_last_update &&
strcmp(istate->fsmonitor_last_update, last_update_token.buf))
istate->cache_changed |= FSMONITOR_CHANGED;
/* Now that we've updated istate, save the last_update_token */
FREE_AND_NULL(istate->fsmonitor_last_update);
istate->fsmonitor_last_update = strbuf_detach(&last_update_token, NULL);