Ben Peart <benpeart@xxxxxxxxxxxxx> 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.
