two-way merge corner case bug

It seems that we have a corner case bug in two-way merge to reset away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".

In a freshly created repository:

    rm -f A Z
    for i in $(seq 100)
    do
            echo hello
    done >Z
    git add Z
    git commit -m initial
    git branch side
    echo goodbye >>Z
    git commit -a -m changed
    git checkout side
    git mv Z A
    echo kitty >>A
    git commit -a -m side

if you do one of these:

	git checkout master && git merge side
	git checkout side && git merge master

you will get three stages for path A, and nothing for path Z.

With the former, you are starting from a tree with Z (and not A), and "resetting" should give you A that is the same as 'master' in the working tree. With the latter, you are starting from a tree with A, and "resetting" should give you Z and remove conflicted A from the working tree.

	git read-tree -u --reset ORIG_HEAD

does the right thing in either case, but

	git read-tree -u --reset HEAD ORIG_HEAD

dies with "cache entry has null sha1: A" for both cases.

The direct symptom comes from 4337b5856f88 (do not write null sha1s to on-disk index, 2012-07-28), but I think the root cause is somewhere else. When we start from 'side', we should notice that our HEAD has Z, and conflicted A we see in the index came from a conflicted merge that we are resetting away and should disappear from the working tree. When we start from 'master', we should notice that we do not want to keep the cache entry that is "modified" in the index, and write the one taken from the "going to" tree (ORIG_HEAD).