Elijah Newren <newren@xxxxxxxxx> writes: > +test_expect_failure '--index-only with rename/modify works in non-bare-clone' ' > + git checkout B^0 && > + > + git merge --index-only -s recursive C^0 && > + > + echo "Making sure the working copy was not updated" && > + test ! -f b && > + test -f a && > + test $(git rev-parse B:a) = $(git hash-object a) && > + > + echo "Making sure the index was updated" && > + test 1 -eq $(git ls-files -s | wc -l) && > + test $(git rev-parse B:a) = $(git rev-parse :b) The most crucial test that is missing (hence prevents reviewers from judging if --index-only is a good idea at all) is the test on HEAD. Does it record a merge between B and C and move HEAD there, i.e. test $(git rev-parse HEAD^1) = $(git rev-parse B) && test $(git rev-parse HEAD^2) = $(git rev-parse C) or does it make a merge but does not advance HEAD, i.e. test $(git rev-parse HEAD) = $(git rev-parse B) I fear that it may give a great headache to end users if you move HEAD in a repository with a working tree to point at the merge result--how do they reconcile the difference between the working tree (which was based on B) and the index and HEAD (which is now based on the result of the merge)? The next "git commit -a" would appear that it would revert the changes brought in by this merge, wouldn't it? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html