Re: [PATCH v2] builtin-commit: Refresh cache after adding files.

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 9, 2007, 19:37 UTC
Message-ID: <7vzlxnrz00.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1194634238-3308-1-git-send-email-krh@redhat.com>

Kristian Høgsberg <krh@redhat.com> writes:

> This fixes the race in the last test in t3700-add.sh.
> add_files_to_cache() should leave the new index stat-clean, but some
> times it doesn't.  Calling refresh_cache() in a few places works
> around this for now.

Sorry, but this description based on my previous observation is not quite right.

As we have been promising users that "git status" will clear away the stat dirtiness, we should call refresh_cache() at the end of prepare_index() regardless of the add_files_to_cache() issue. We need to refresh_cache() the whole thing, even if we fixed add_files_to_cache() to add entries that are stat clean, so this is not a workaround but implementation of the advertised behaviour. It does hide the problem add_files_to_cache() seems to have, which we would need to fix independently.

I think the additional refresh_cache() for the user index you did is also the right thing to do for the same reason.

> Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> ---
>
> Should we add the refresh_cache() call in add_files_to_cache() instead?

I do not think so. These two functions, add_files_to_cache() and add_file_to_cache(), should make the entries they add to the index stat-clean, but they should not spend extra cycles scanning the whole index and re-statting the whole tree to refresh entries the user did not mention.