Junio C Hamano schrieb:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> 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
-
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
