Re: git pull failure, truncated object

From: Shawn O. Pearce <spearce@spearce.org>
Date: May 8, 2007, 14:59 UTC
Message-ID: <20070508145916.GQ11311@spearce.org>
In-Reply-To: <17984.35097.568689.482933@lisa.zopyra.com>

Bill Lear <rael@zopyra.com> wrote: ...

> error: failed to read delta-pack base object
> 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d
> fatal: unpack-objects died with error code 1

Danger Will Robinson! Danger! Your repository is not acting normally...

> So, I looked in the man page of git-gc and thought to try --prune,
> as this was not an active repository.  This worked, and then
> the pull did as well.

Don't run git-gc on a repository that is acting strangely, unless you have concluded that the correct course of action is to just repack the repository. (It rarely is, btw.) You could make things worse if a packfile contains a corrupt object and you have the same valid loose object; a gc would delete the valid object and keep the corrupt one.

Show 6 quoted lines

> I'm wondering why git-gc did not at least warn us of this problem when
> we tried it.  It appeared to us that git-gc gave our repo a clean bill
> of health, and so we turned our attention to the remote and
> investigated there, instead of continuing in the local repo.
> 
> Should we have tried git fsck instead in this case?

Yes, git-fsck is meant for checking the "health" of a repository. In this case it should have caught the 0 length object and told you that loose object was corrupt. A sure sign that you have a problem. If you have a loose object problem, `git prune` might fix it, as it did here, but only if that object isn't actually needed. A `git fsck` immediately after would tell you if the prune fixed the issue, or not.

-- 
Shawn.