Christian [off-list ref] writes:
The central machine is a AMD Sempron, it runs Debian Sarge (3.1)
We've installed git from source, because sarge has it not in its
archives.
Maybe we did something wrong at building time ? or you're right and
the debian sarge zlib does not fit good to the current git versions ?
What I have been suspecting since I got that not-corrupted but
reported to be corrupt tree is that the version running on your
"unable to fsck" machine -- the one you use as the central
machine -- has a dud (or miscompiled) version of git, which
somehow reports corruption incorrectly on perfectly good
objects when it validates it before using them.
And to that machine, push over http succeeds fine only because
push over http is "dangerous" in that it does not "validate" the
pushed data on the receiving end like other codepaths do.
It would be interesting to find out what the breakage is on that
central machine. I think enough people run Sarge that it is
unlikely it's zlib at fault, but the way git uses the zlib API,
which was cleaned up in the current tree with the two fixes from
Linus I mentioned earlier.
Junio C Hamano wrote:
Christian [off-list ref] writes:
quoted
The central machine is a AMD Sempron, it runs Debian Sarge (3.1)
We've installed git from source, because sarge has it not in its
archives.
Maybe we did something wrong at building time ? or you're right and
the debian sarge zlib does not fit good to the current git versions ?
What I have been suspecting since I got that not-corrupted but
reported to be corrupt tree is that the version running on your
"unable to fsck" machine -- the one you use as the central
machine -- has a dud (or miscompiled) version of git, which
somehow reports corruption incorrectly on perfectly good
objects when it validates it before using them.
well if you like i can give you an account to that machine offlist, i
could show you in a screen session where everything is.
And to that machine, push over http succeeds fine only because
push over http is "dangerous" in that it does not "validate" the
pushed data on the receiving end like other codepaths do.
It would be interesting to find out what the breakage is on that
central machine. I think enough people run Sarge that it is
unlikely it's zlib at fault, but the way git uses the zlib API,
which was cleaned up in the current tree with the two fixes from
Linus I mentioned earlier.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html