Re: [RFC/PATCH 05/18] Add testcase for --index-only merges needing the recursive strategy

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> 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?