Re: What's not in 'master', and likely not to be in, until 1.5.4

Junio C Hamano schrieb:

Junio C Hamano [off-list ref] writes:

quoted

It's a Heisenbug.  I actually merged it to 'next' but rewound it
before pushing the result out after seeing a breakage.

"make clean test" to run everything through sometimes fails and
immediately after that when I do "cd t && sh t75??-???.sh -i -v"
it happily runs through the end.

I'll be back with more details when I have some.

In t7501-commit.sh, "partial commit that involves removal (1)"
test, it _sometimes_ fails.

    test_expect_success 'partial commit that involves removal (1)' '

        git rm --cached file &&
        mv file elif &&
        git add elif &&
        git diff-index --name-status HEAD >changes &&
        git commit -m "Partial: add elif" elif &&
        git diff-tree --name-status HEAD^ HEAD >current &&
        echo "A     elif" >expected &&
        diff expected current

    '

It removes "file" from the index, adds "elif" to the index, and
tries to commit _only_ the addition of "elif" without recording
the removal of "file" (I added "diff-index" above to see where
it fails, its presense or absense does not change the bug, and
it shows that both addition of elif and removal of file are in
the index).

When the test fails, the resulting commit however does not
record the addition of elif.  The commit records the same tree
as its parent instead.  The index that is left has "elif" but
not "file" (iow, it records the expected state after such a
partial commit).

Déjà-vu! We had similar problems on Windows. I was able to solve it this
way when git-commit was still a shell script:

 save_index () {
-	cp -p "$THIS_INDEX" "$NEXT_INDEX"
+	ln "$THIS_INDEX" "$NEXT_INDEX"
 }

because 'cp -p' does not keep the precise timestamp, but 'ln' does (which
creates hardlinks on NTFS). This violated the assumptions on which the
racy-git check relies.

-- Hannes