Show 38 quoted lines
> Torsten Bögershausen <tboegi@web.de> writes:
>
>> Now it appeared on next as well, so it's time to look a little bit deeper.
>>
>> This test case of t1450 fails:
>> test_expect_success 'tag pointing to something else than its type' '
>>
>> To debug more, I added an exit 0 here to inspect the file named out:
>> diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
>> index 5b79c51..f1f45c9 100755
>> --- a/t/t1450-fsck.sh
>> +++ b/t/t1450-fsck.sh
>> @@ -179,6 +179,7 @@ test_expect_success 'tag pointing to something else than its type' '
>> test_when_finished "git update-ref -d refs/tags/wrong" &&
>> test_must_fail git fsck --tags 2>out &&
>> cat out &&
>> + exit 0
>> grep "error in tag.*broken links" out
>> '
>>
>> Linux:
>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object
>>
>> Mac OS X:
>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
>> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
>
> What OS X are you running? I started a loop
>
> while : ; do ./t1450-fsck.sh || break; done
>
> and it hasn't failed yet. It is
>
> $ uname -a
> Darwin mackeller.inf.ethz.ch 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
>
That lloks like this:
fileA
ctime: 1342453768:0
mtime: 1342453768:0
dev: 234881026 ino: 92698027
uid: 1500 gid: 20
size: 4 flags: 5
fileB
ctime: 1342453768:0
mtime: 1342453768:0
dev: 234881026 ino: 92698053
uid: 1500 gid: 20
size: 4 flags: 5
==================
But what is interesting, is that
a) When I clone a fresh copy from git.git, it works OK. After some activity with the working dir,
suddenly t1450 fails. Switching back to e.g. v1.7.11 makes t1450 pass again.
Switching to origin/next , running make brings back the problem, t1450 fails
b) The failure seems to be time critical. When I run the test yesterday evening,
being logged in via ssh makes the test pass.
Sitting at the machine makes it fail.
c) It seems as if there is a problem when writing to disk.
Could be the index file
(git ls-files --debug does not dump the whole index, does it?)
d) As Peff pointed out, the fsck itself is not time critical.
Thanks for looking into it