read-cache: fix untracked cache invalidation when split-index is used

Before this change, t7063.17 fails. The actual action though happens at
t7063.16 where the entry "two" is added back to index after being
removed in the .13. Here we expect a directory invalidate at .16 and
none at .17 where untracked cache is refreshed. But things do not go as
expected when GIT_TEST_SPLIT_INDEX is set.

The different behavior that happens at .16 when split index is used: the
entry "two", when deleted at .13, is simply marked "deleted". When .16
executes, the entry resurfaces from the version in base index. This
happens in merge_base_index() where add_index_entry() is called to add
"two" back from the base index.

This is where the bug comes from. The add_index_entry() is called with
ADD_CACHE_KEEP_CACHE_TREE flag because this version of "two" is not new,
it does not break either cache-tree or untracked cache. The code should
check this flag and not invalidate untracked cache. This causes a second
invalidation violates test expectation. The fix is obvious.

Noticed-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/read-cache.c b/read-cache.c
index 705469eb7a90f3168acec47740d6b8b6b2661864..34d2e5ea428895253180c26c6eb3db6c6e032ed3 100644 (file)
--- a/read-cache.c
+++ b/read-cache.c
@@ -997,7 +997,8 @@ static int add_index_entry_with_check(struct index_state *istate, struct cache_e
        }
        pos = -pos-1;
 
-       untracked_cache_add_to_index(istate, ce->name);
+       if (!(option & ADD_CACHE_KEEP_CACHE_TREE))
+               untracked_cache_add_to_index(istate, ce->name);
 
        /*
         * Inserting a merged entry ("stage 0") into the index