recent 'unpack_trees()'-related changes break 'git stash'

Hi,

t3903-stash.sh _sometimes_ fails at the 'drop middle stash' testcase. After playing around with it this evening I was able to narrow it down, and turned out that it has nothing to do with 'git stash drop', but something is broken behind 'stash'.

Unfortunately, I can't reproduce the bug reliably. Here is a testcase, that sometimes fails:

test_description='Test git-stash'
. ./test-lib.sh
test_expect_success 'try to catch some rare occurring stash bug' '
	echo 1 > file &&
	git add file &&
	test_tick &&
	git commit -m initial &&
	echo 2 > file &&
	test_tick &&
	git stash &&
	test 2 = $(git stash show stash@{0} | wc -l) &&
	echo "after first show test"
	echo 3 > file &&
	git stash &&
	test 2 = $(git stash show stash@{0} | wc -l) &&
	echo "after second show test"
'
test_done

and here is a loop to run the above testcase until it fails (take care, it deletes ./trash at the beginning!):

ret=0
i=0
while test $ret = 0 ; do
	rm -rf ./trash
	./mystashtest.sh --verbose
	ret=$?
	i=$((++i))
done
echo "test failed at ${i}. run"

Both should go into t/ directory.

The testcase usually fails during the first 25 run, but sometimes it runs more than 100 times before failing. The test fails because the second 'git stash' sometimes does something wrong: there is no difference between stash@{0} and the clean working tree. There is no error message from 'git stash' upon failure. During all the test runs I never saw a failure occuring at the first 'git stash'.

I ran bisect using these scripts, and it turned out that the bug was introduced by 34110cd4 (Make 'unpack_trees()' have a separate source and destination index, 2008-03-06).

I have tried whether it has already been fixed in next or pu, but those branches are affected, too.

Best, Gábor