Ben Peart <benpe...@microsoft.com> writes: > +/* do stat comparison even if CE_FSMONITOR_VALID is true */ > +#define CE_MATCH_IGNORE_FSMONITOR 0X20
Hmm, when should a programmer use this flag? > +int git_config_get_fsmonitor(void) > +{ > + if (git_config_get_pathname("core.fsmonitor", &core_fsmonitor)) > + core_fsmonitor = getenv("GIT_FSMONITOR_TEST"); Will the environment be part of the published API, or is it a remnant of a useful tool for debugging while developing the feature? If it is the former (and I'd say why not, even though "git -c core.fsmontor=..." may be easy enough), we might want to rename it to replace _TEST with _PROGRAM or something and document it. > diff --git a/diff-lib.c b/diff-lib.c > index 2a52b07954..23c6d03ca9 100644 > --- a/diff-lib.c > +++ b/diff-lib.c > @@ -12,6 +12,7 @@ > #include "refs.h" > #include "submodule.h" > #include "dir.h" > +#include "fsmonitor.h" > > /* > * diff-files > @@ -228,6 +229,7 @@ int run_diff_files(struct rev_info *revs, unsigned int > option) > > if (!changed && !dirty_submodule) { > ce_mark_uptodate(ce); > + mark_fsmonitor_valid(ce); I notice all calls to mark_fsmonitor_valid(ce) always follow a call to ce_mark_uptodate(ce). Should the call to the former be made as part of the latter instead? Are there cases where we want to call ce_mark_uptodate(ce) to mark the ce up-to-date, yet we do not want to call mark_fsmonitor_valid(ce)? How does a programmer tell when s/he wants to call ce_mark_uptodate(ce) if s/he also should call mark_fsmonitor_valid(ce)? Together with "when to pass IGNORE_FSMONITOR" question, is there a summary that guides new programmers to answer these questions in the new documentation? > diff --git a/dir.h b/dir.h > index e3717055d1..fab8fc1561 100644 > --- a/dir.h > +++ b/dir.h > @@ -139,6 +139,8 @@ struct untracked_cache { > int gitignore_invalidated; > int dir_invalidated; > int dir_opened; > + /* fsmonitor invalidation data */ > + unsigned int use_fsmonitor : 1; This makes it look like we will add a bit more fields in later patches that are about "invalidation" around fsmonitor, but it appears that such an addition never happens til the end of the series. And use_fsmonitor boolean does not seem to be what the comment says---it just tells us if fsmonitor is in use in the operation of the untracked cache, no? > diff --git a/entry.c b/entry.c > index cb291aa88b..5e6794f9fc 100644 > --- a/entry.c > +++ b/entry.c > @@ -4,6 +4,7 @@ > #include "streaming.h" > #include "submodule.h" > #include "progress.h" > +#include "fsmonitor.h" > > static void create_directories(const char *path, int path_len, > const struct checkout *state) > @@ -357,6 +358,7 @@ static int write_entry(struct cache_entry *ce, > lstat(ce->name, &st); > fill_stat_cache_info(ce, &st); > ce->ce_flags |= CE_UPDATE_IN_BASE; > + mark_fsmonitor_invalid(state->istate, ce); > state->istate->cache_changed |= CE_ENTRY_CHANGED; Similar to "how does mark_fsmonitor_valid() relate to ce_mark_uptodate()?" question earlier, mark_fsmonitor_invalid() seems to often appear in pairs with the update to cache_changed. Are there cases where we need CE_ENTRY_CHANGED bit added to the index state yet we do not want to call mark_fsmonitor_invalid()? I am wondering if there should be a single helper function that lets callers say "I changed this ce in this istate this way. Please update CE_VALID, CE_UPDATE_IN_BASE and CE_FSMONITOR_VALID accordingly". That "changed _this way_" is deliberately vague in my question above, because it is not yet clear to me when mark-valid and mark-invalid should and should not be called from the series. > + /* a fsmonitor process can return '*' to indicate all entries are > invalid */ > + if (query_success && query_result.buf[0] != '/') { > + /* Mark all entries returned by the monitor as dirty */ The comment talks about '*' and code checks if it is not '/'? The else clause of this if/else handles the "invalidate all" case, so shouldn't we be comparing with '*' instead here? Ah, fsmonitor-watchman section of the doc tells us to write the hook in a way to return slash, so the comment above the code is stale and the comparison with '/' is what we want, I guess.