* [PATCH v2] builtin-commit: Refresh cache after adding files.
@ 2007-11-09 18:50 Kristian Høgsberg
2007-11-09 19:37 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: Kristian Høgsberg @ 2007-11-09 18:50 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Schindelin, 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
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH v2] builtin-commit: Refresh cache after adding files.
2007-11-09 18:50 [PATCH v2] builtin-commit: Refresh cache after adding files Kristian Høgsberg
@ 2007-11-09 19:37 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2007-11-09 19:37 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, Johannes Schindelin
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-11-09 19:38 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-09 18:50 [PATCH v2] builtin-commit: Refresh cache after adding files Kristian Høgsberg
2007-11-09 19:37 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).