Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

Re: git pull failure, truncated object

From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:43:09

Bill Lear [off-list ref] 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.
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help