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
--
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
