Avoid "diff-index --cached" optimization under --find-copies-harder

When find-copies-harder is in effect, the diff frontends are expected to
feed all paths, not just changed paths, to the diffcore, so that copy
sources can be picked up.  In such a case, not descending into subtrees
using the cache-tree information is simply wrong.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/diff-lib.c b/diff-lib.c
index 1cb97af22d0f1d3f5ea6cc37a86df4b14b52d1f7..ae75eacbcc00cd7d27d415c91eac5b819db4221e 100644 (file)
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -446,7 +446,8 @@ int run_diff_index(struct rev_info *revs, int cached)
        memset(&opts, 0, sizeof(opts));
        opts.head_idx = 1;
        opts.index_only = cached;
-       opts.diff_index_cached = cached;
+       opts.diff_index_cached = (cached &&
+                                 !DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER));
        opts.merge = 1;
        opts.fn = oneway_diff;
        opts.unpack_data = revs;
@@ -503,7 +504,7 @@ int do_diff_cache(const unsigned char *tree_sha1, struct diff_options *opt)
        memset(&opts, 0, sizeof(opts));
        opts.head_idx = 1;
        opts.index_only = 1;
-       opts.diff_index_cached = 1;
+       opts.diff_index_cached = !DIFF_OPT_TST(opt, FIND_COPIES_HARDER);
        opts.merge = 1;
        opts.fn = oneway_diff;
        opts.unpack_data = &revs;

diff --git a/t/t4007-rename-3.sh b/t/t4007-rename-3.sh
index 25e7a836598512878494865c1a3dca801e8b12e3..11502b750997aba0ecfb6aa5b07c9aad1c45d592 100755 (executable)
--- a/t/t4007-rename-3.sh
+++ b/t/t4007-rename-3.sh
@@ -35,6 +35,11 @@ test_expect_success 'copy detection' '
        compare_diff_raw current expected
 '
 
+test_expect_success 'copy detection, cached' '
+       git diff-index -C --find-copies-harder --cached $tree >current &&
+       compare_diff_raw current expected
+'
+
 # In the tree, there is only path0/COPYING.  In the cache, path0 and
 # path1 both have COPYING and the latter is a copy of path0/COPYING.
 # However when we say we care only about path1, we should just see