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

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

[Kristian Høgsberg]

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.

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---

Should we add the refresh_cache() call in add_files_to_cache() instead?

 builtin-commit.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index 7dc8977..81539c8 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -81,6 +81,7 @@ static char *prepare_index(const char **files, const char *prefix)
 
 	if (all || also) {
 		add_files_to_cache(verbose, also ? prefix : NULL, files);
+		refresh_cache(REFRESH_QUIET);
 		if (write_cache(fd, active_cache, active_nr) || close(fd))
 			die("unable to write new_index file");
 		return lock_file.filename;
@@ -94,6 +95,7 @@ static char *prepare_index(const char **files, const char *prefix)
 
 	/* update the user index file */
 	add_files_to_cache(verbose, prefix, files);
+	refresh_cache(REFRESH_QUIET);
 	if (write_cache(fd, active_cache, active_nr) || close(fd))
 		die("unable to write new_index file");
 
@@ -110,6 +112,7 @@ static char *prepare_index(const char **files, const char *prefix)
 	fd = hold_lock_file_for_update(next_index_lock,
 				       git_path("next-index-%d", getpid()), 1);
 	add_files_to_cache(verbose, prefix, files);
+	refresh_cache(REFRESH_QUIET);
 	if (write_cache(fd, active_cache, active_nr) || close(fd))
 		die("unable to write new_index file");
 
-- 
1.5.3.4.206.g58ba4

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

[Junio C Hamano]

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.