David Turner <dtur...@twopensource.com> writes:
> During the commit process, the cache-tree is updated. We need to write
> this updated cache-tree so that it's ready for subsequent commands.
>
> Add test code which demonstrates that git commit now writes the cache
> tree. Also demonstrate that cache-tree invalidation is correct.
>
> Signed-off-by: David Turner <dtur...@twitter.com>
> ---
> builtin/commit.c | 15 ++++++------
> t/t0090-cache-tree.sh | 63
> ++++++++++++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 67 insertions(+), 11 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 9cfef6c..dbd4f4b 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -342,6 +342,8 @@ static char *prepare_index(int argc, const char **argv,
> const char *prefix,
>
> discard_cache();
> read_cache_from(index_lock.filename);
> + if (update_main_cache_tree(WRITE_TREE_SILENT) >= 0)
> + write_cache(fd, active_cache, active_nr);
OK, interactive-add may leave the cache-tree not quite populated;
we are going to write out a tree from the cache so we need to update
the in-core cache tree anyway, so calling update-main-cache-tree
here would not hurt (it will speed up the write-cache-as-tree we
will eventually call).
We might want to see if we are really changing anything, though.
What happens if the interactive-add gave us an index with fully
valid cache-tree? Is that rare enough not to matter (not a
rhetorical question)?
> @@ -383,14 +385,10 @@ static char *prepare_index(int argc, const char **argv,
> const char *prefix,
> if (!only && !pathspec.nr) {
> fd = hold_locked_index(&index_lock, 1);
> refresh_cache_or_die(refresh_flags);
> - if (active_cache_changed) {
> - update_main_cache_tree(WRITE_TREE_SILENT);
> - if (write_cache(fd, active_cache, active_nr) ||
> - commit_locked_index(&index_lock))
> - die(_("unable to write new_index file"));
> - } else {
> - rollback_lock_file(&index_lock);
> - }
> + update_main_cache_tree(WRITE_TREE_SILENT);
> + if (write_cache(fd, active_cache, active_nr) ||
> + commit_locked_index(&index_lock))
> + die(_("unable to write new_index file"));
How about doing this part like the following instead, so that we can
avoid the overhead of uselessly rewriting the index file when we do
not have to?
diff --git a/builtin/commit.c b/builtin/commit.c
index 5e2221c..7d730a5 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -383,8 +383,11 @@ static char *prepare_index(int argc, const char **argv,
const char *prefix,
if (!only && !pathspec.nr) {
fd = hold_locked_index(&index_lock, 1);
refresh_cache_or_die(refresh_flags);
- if (active_cache_changed) {
+ if (active_cache_changed ||
!cache_tree_fully_valid(active_cache_tree)) {
update_main_cache_tree(WRITE_TREE_SILENT);
+ active_cache_changed = 1;
+ }
+ if (active_cache_changed) {
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
die(_("unable to write new_index file"));
It makes me wonder if we should teach update_main_cache_tree() to
somehow smudge active_cache_changed bit as necessary. Then we do
not have to make the call to update-main-cache-tree conditional.
> @@ -435,6 +433,7 @@ static char *prepare_index(int argc, const char **argv,
> const char *prefix,
> fd = hold_locked_index(&index_lock, 1);
> add_remove_files(&partial);
> refresh_cache(REFRESH_QUIET);
> + update_main_cache_tree(WRITE_TREE_SILENT);
> if (write_cache(fd, active_cache, active_nr) ||
> close_lock_file(&index_lock))
> die(_("unable to write new_index file"));
This is the index that will be used after we create the commit
(which will be created from a temporary index that will be discarded
immediately after we create the commit). As we _know_ we are
changing something in this code path by calling add_remote_files(),
it is fine to call update-main-cache-tree here unconditionally.
I didn't notice it when I gave the previous review comment but while
reviewing this round, we already do the cache-tree population for
"commit -a" in this function, which suggests me that it is the right
place to do these changes. Modulo minor niggles, I like this
iteration much better than the previous one.
Thanks for working on this.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
