Subject: Re: [PATCH v2 15/16] fsmonitor: refactor bit invalidation in refresh callback

From: Junio C Hamano <[email-masked]>
Date: Fri, 23 Feb 2024 10:18:11 -0800

"Jeff Hostetler via GitGitGadget" <[email-masked]> writes:

> From: Jeff Hostetler <[email-masked]>
>
> Refactor code in the fsmonitor_refresh_callback() call chain dealing
> with invalidating the CE_FSMONITOR_VALID bit and add a trace message.
>
> During the refresh, we clear the CE_FSMONITOR_VALID bit in response to
> data from the FSMonitor daemon (so that a later phase will lstat() and
> verify the true state of the file).
>
> Create a new function to clear the bit and add some unique tracing for
> it to help debug edge cases.
>
> This is similar to the existing `mark_fsmonitor_invalid()` function,
> but we don't need the extra stuff that it does.
>
> Signed-off-by: Jeff Hostetler <[email-masked]>
> ---
>  fsmonitor.c | 20 +++++++++++++++++---
>  1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/fsmonitor.c b/fsmonitor.c
> index ac638a61c00..0667a8c297c 100644
> --- a/fsmonitor.c
> +++ b/fsmonitor.c
> @@ -187,6 +187,20 @@ static int query_fsmonitor_hook(struct repository *r,
>  static size_t handle_path_with_trailing_slash(
>  	struct index_state *istate, const char *name, int pos);
>  
> +/*
> + * Invalidate the FSM bit on this CE.  This is like mark_fsmonitor_invalid()
> + * but we've already handled the untracked-cache and I want a different
> + * trace message.
> + */

"I want" -> "want" perhaps.

More importantly, when new developers come and want to touch this
file in the future, how would they choose which one to call?  Would
it make a better comment if we rewrote the above for such future
developers as intended audiences?

> +static void invalidate_ce_fsm(struct cache_entry *ce)
> +{
> +	if (ce->ce_flags & CE_FSMONITOR_VALID)
> +		trace_printf_key(&trace_fsmonitor,
> +				 "fsmonitor_refresh_callback INV: '%s'",
> +				 ce->name);
> +	ce->ce_flags &= ~CE_FSMONITOR_VALID;
> +}
> +
>  /*
>   * Use the name-hash to do a case-insensitive cache-entry lookup with
>   * the pathname and invalidate the cache-entry.
> @@ -224,7 +238,7 @@ static size_t handle_using_name_hash_icase(
>  
>  	untracked_cache_invalidate_trimmed_path(istate, ce->name, 0);
>  
> -	ce->ce_flags &= ~CE_FSMONITOR_VALID;
> +	invalidate_ce_fsm(ce);
>  	return 1;
>  }
>  
> @@ -316,7 +330,7 @@ static size_t handle_path_without_trailing_slash(
>  		 * cache-entry with the same pathname, nor for a cone
>  		 * at that directory. (That is, assume no D/F conflicts.)
>  		 */
> -		istate->cache[pos]->ce_flags &= ~CE_FSMONITOR_VALID;
> +		invalidate_ce_fsm(istate->cache[pos]);
>  		return 1;
>  	} else {
>  		size_t nr_in_cone;
> @@ -394,7 +408,7 @@ static size_t handle_path_with_trailing_slash(
>  	for (i = pos; i < istate->cache_nr; i++) {
>  		if (!starts_with(istate->cache[i]->name, name))
>  			break;
> -		istate->cache[i]->ce_flags &= ~CE_FSMONITOR_VALID;
> +		invalidate_ce_fsm(istate->cache[i]);
>  		nr_in_cone++;
>  	}

Nice.