"Victoria Dye via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > diff --git a/read-cache.c b/read-cache.c > index 1ad56d02e1d..2c5ccc48d6c 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -148,6 +148,7 @@ void rename_index_entry_at(struct index_state *istate, int nr, const char *new_n > untracked_cache_remove_from_index(istate, old_entry->name); > remove_index_entry_at(istate, nr); > add_index_entry(istate, new_entry, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE); > + refresh_cache_entry(istate, new_entry, CE_MATCH_REFRESH); > } This is a bit unforunate. If we are renaming "foo" to "bar", I wonder if we can grab the cached stat info before calling remove_index_entry_at() for "foo" and copy it to the new entry we create for "bar". After all, we would be making a corresponding change to rename from "foo" to "bar" at the filesystem level, too, no? Well, we are already doing that by calling copy_cache_entry(). So why do we further need to refresh the cache entry in the first place? There is something fishy going on, isn't it? Puzzling... In any case, refresh_cache_entry() either returns ce or create a newly allocated entry, so you'd want to first refresh and then the add the cache entry returned from the function to the index, I think. Thanks.
