Re: git 1.5.1-rc1 doesn't like empty files

From: Shawn O. Pearce <spearce@spearce.org>
Date: Mar 20, 2007, 05:56 UTC
Message-ID: <20070320055611.GD29288@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0703192237100.6730@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 16 quoted lines

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