In
456156d a shortcut to priming the index tree reference was
introduced, but the justification for it was completely bogus.
"read-tree -m A B" is to take the index (and the working tree)
that is largely based on (but does not have to match exactly) A
and update it to B, while carrying the local change that does
not overlap the difference between A and B, so there is no reason
to expect that the resulting index should match the tree B.
Noticed and test provided by Heiko Voigt.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* "-m ent" or "--reset ent" form), we can obtain a fully
* valid cache-tree because the index must match exactly
* what came from the tree.
- *
- * The same holds true if we are switching between two trees
- * using read-tree -m A B. The index must match B after that.
*/
if (nr_trees == 1 && !opts.prefix)
prime_cache_tree(&active_cache_tree, trees[0]);
- else if (nr_trees == 2 && opts.merge)
- prime_cache_tree(&active_cache_tree, trees[1]);
if (write_cache(newfd, active_cache, active_nr) ||
commit_locked_index(&lock_file))
git ls-files --stage | tee >treeMcheck.out &&
test_cmp treeM.out treeMcheck.out'
+test_expect_success '-m references the correct modified tree' '
+ echo >file-a &&
+ echo >file-b &&
+ git add file-a file-b &&
+ git commit -a -m "test for correct modified tree"
+ git branch initial-mod &&
+ echo b >file-b &&
+ git commit -a -m "B" &&
+ echo a >file-a &&
+ git add file-a &&
+ git ls-tree $(git write-tree) file-a >expect &&
+ git read-tree -m HEAD initial-mod &&
+ git ls-tree $(git write-tree) file-a >actual &&
+ test_cmp expect actual
+'
+
test_done