Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html