Linus Torvalds <torvalds@linux-foundation.org> wrote:
quoted text
> On Tue, 20 Mar 2007, Pavel Roskin wrote:
> > 
> > .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 is the same 9
> > bytes:  30 78 9c 03 00 00 00 00 01
> 
> Ahh.. You have
> 
> 	[core]
> 		legacyheaders = false
> 
> don't you? If you didn't, you should see a 15-byte object, not a 9-byte 
> one.
> 
> And yes, I can reproduce this with that "core.legacyheaders=false" 
> setting. It seems that config option is simply broken, and we never 
> noticed, because almost nobody uses it.

For what it is worth, I have been running core.legacyheaders=false
on both my PowerBook (my main dev system) and on my x86 Cygwin
POS.  I guess I've been lucky, as I've never noticed any sort
of corruption.

Oh, wait, yes I did.  Just the other day.  A loose object got the
same zlib error as Pavel asked about.  But git-prune whacked the
damn thing.  I figured it was just a short write by Cygwin during
some sort of operation that I may have aborted; e.g. aborting an
update-index and running it again later, thus never actually using
that particular blob.

I didn't think twice about the error (until now), especially since
`git-fsck --full` did not whine after the corrupt loose object
was gone.

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