Re: git pull failure, truncated object

On Tue, 8 May 2007, Bill Lear wrote:

On Tuesday, May 8, 2007 at 11:41:14 (-0400) Nicolas Pitre writes:

quoted

On Tue, 8 May 2007, Bill Lear wrote:

quoted

He did a git-gc, twice, and retried.  Still failed.

So, he called me in and we tried to see if the server was acting up

--- perhaps an NFS problem, as we've had those before, but got very

different error messages.  Watched the log file from git-daemon, and
saw nothing.  Finally we took a look at the local repos
.git/objects/4b, and 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d was of
length 0.

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.

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.

git-gc != git-fsck.

Indeed, as is now clear to me.  Would it be prudent to have git-gc
run a quick git-fsck internally and warn if things are not in a kosher
state?

No.  git-fsck is a potentially expensive operation and it is up to you 
to remember that git-gc isn't about repository sanity. git-gc only 
repacks things and if it encounters an object that is corrupt it will 
abort and leave your object store as is.  In your case the corrupted 
object wasn't one that needed to be repacked which explains why git-gc 
succeeded.


Nicolas