Re: [PATCH] fsmonitor: invalidate untracked cache after losing history
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 4, 2026, 20:39 UTC
- Message-ID
- <xmqq1p901gd7.fsf@gitster.g>
- In-Reply-To
- <pull.2295.git.1793806679163.gitgitgadget@gmail.com>
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 48 quoted lines
> +static void invalidate_directory_recursive(struct untracked_cache *uc,
> + struct untracked_cache_dir *ucd)
> +{
> + invalidate_one_directory(uc, ucd);
> + for (size_t i = 0; i < ucd->dirs_nr; i++)
> + invalidate_directory_recursive(uc, ucd->dirs[i]);
> +}
> +
> +void untracked_cache_invalidate_all(struct index_state *istate)
> +{
> + if (!istate->untracked || !istate->untracked->root)
> + return;
> +
> + invalidate_directory_recursive(istate->untracked,
> + istate->untracked->root);
> + istate->cache_changed |= UNTRACKED_CHANGED;
> +}
> +
> /*
> * Normally when an entry is added or removed from a directory,
> * invalidating that directory is enough. No need to touch its
> diff --git a/dir.h b/dir.h
> index 83e0f648a8..d2de762da8 100644
> --- a/dir.h
> +++ b/dir.h
> @@ -596,6 +596,7 @@ static inline int dir_path_match(struct index_state *istate,
> int cmp_dir_entry(const void *p1, const void *p2);
> int check_dir_entry_contains(const struct dir_entry *out, const struct dir_entry *in);
>
> +void untracked_cache_invalidate_all(struct index_state *);
> void untracked_cache_invalidate_path(struct index_state *, const char *, int safe_path);
> /*
> * Invalidate the untracked-cache for this path, but first strip
> diff --git a/fsmonitor.c b/fsmonitor.c
> index 107767527e..9c3079f64a 100644
> --- a/fsmonitor.c
> +++ b/fsmonitor.c
> @@ -713,8 +713,10 @@ apply_results:
> if (is_cache_changed)
> istate->cache_changed |= FSMONITOR_CHANGED;
>
> - if (istate->untracked)
> + if (istate->untracked) {
> + untracked_cache_invalidate_all(istate);
> istate->untracked->use_fsmonitor = 0;
> + }
> }
> trace2_region_leave("fsmonitor", "apply_results", istate->repo);That is rather a blunt instrument, but being without acceleration is much better than being fast and incorrect.
Will queue. Thanks.