{"thread":{"id":"8033","subject":"git pull failure, truncated object","startedAt":"2007-05-08T14:28:41Z","lastAt":"2007-05-08T17:51:57Z","messageCount":6,"participants":["Bill Lear","Shawn O. Pearce","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41454","messageId":"17984.35097.568689.482933@lisa.zopyra.com","threadId":"8033","inReplyTo":null,"subject":"git pull failure, truncated object","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-05-08T14:28:41Z","receivedAt":"2007-05-08T14:28:41Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"Our QA dude had a disk fill up a while back.  Forgot about it.  Went\nto pull during a nightly build.  Got this:\n\n% git pull\nremote: Generating pack...\nremote: Done counting 104 objects.\nremote: Result has 72 objects.\nremote: Deltifying 72 objects.\nremote:  100% (72/72) done\nUnpacking 72 objects\nremote: Total 72 (delta 46), reused 52 (delta 26)\nerror: failed to read delta-pack base object\n4b93eb81265ea4f2b436618a4b1c3bea2bedf06d\nfatal: unpack-objects died with error code 1\n\nHe did a git-gc, twice, and retried.  Still failed.\n\nSo, he called me in and we tried to see if the server was acting up\n--- perhaps an NFS problem, as we've had those before, but got very\ndifferent error messages.  Watched the log file from git-daemon, and\nsaw nothing.  Finally we took a look at the local repos\n.git/objects/4b, and 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d was of\nlength 0.\n\nSo, I looked in the man page of git-gc and thought to try --prune,\nas this was not an active repository.  This worked, and then\nthe pull did as well.\n\nI'm wondering why git-gc did not at least warn us of this problem when\nwe tried it.  It appeared to us that git-gc gave our repo a clean bill\nof health, and so we turned our attention to the remote and\ninvestigated there, instead of continuing in the local repo.\n\nShould we have tried git fsck instead in this case?\n\nIt might be nice to have a better error message in this case, one\nthat locates the problem in the local repo.\n\nIf the failure is a short/bad (?) read of a local object, then it\nmight be nice to say something like:\n\nerror: this repo's local object 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d\n       in .git/objects/4b is corrupt.  You will need to run\n       XXX to diagnose and YYY to repair this.\n\nOr some such.\n\n\nBill\n"},{"id":"41459","messageId":"20070508145916.GQ11311@spearce.org","threadId":"8033","inReplyTo":"17984.35097.568689.482933@lisa.zopyra.com","subject":"Re: git pull failure, truncated object","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-08T14:59:16Z","receivedAt":"2007-05-08T14:59:16Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Bill Lear <rael@zopyra.com> wrote:\n...\n> error: failed to read delta-pack base object\n> 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d\n> fatal: unpack-objects died with error code 1\n\nDanger Will Robinson!  Danger!  Your repository is not acting\nnormally...\n\n> So, I looked in the man page of git-gc and thought to try --prune,\n> as this was not an active repository.  This worked, and then\n> the pull did as well.\n\nDon't run git-gc on a repository that is acting strangely, unless\nyou have concluded that the correct course of action is to just\nrepack the repository.  (It rarely is, btw.)  You could make things\nworse if a packfile contains a corrupt object and you have the\nsame valid loose object; a gc would delete the valid object and\nkeep the corrupt one.\n\n> I'm wondering why git-gc did not at least warn us of this problem when\n> we tried it.  It appeared to us that git-gc gave our repo a clean bill\n> of health, and so we turned our attention to the remote and\n> investigated there, instead of continuing in the local repo.\n> \n> Should we have tried git fsck instead in this case?\n\nYes, git-fsck is meant for checking the \"health\" of a repository.\nIn this case it should have caught the 0 length object and told\nyou that loose object was corrupt.  A sure sign that you have a\nproblem.  If you have a loose object problem, `git prune` might\nfix it, as it did here, but only if that object isn't actually\nneeded.  A `git fsck` immediately after would tell you if the\nprune fixed the issue, or not.\n\n-- \nShawn.\n"},{"id":"41461","messageId":"20070508150536.GR11311@spearce.org","threadId":"8033","inReplyTo":"20070508145916.GQ11311@spearce.org","subject":"Re: git pull failure, truncated object","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-08T15:05:36Z","receivedAt":"2007-05-08T15:05:36Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> wrote:\n> Don't run git-gc on a repository that is acting strangely, unless\n> you have concluded that the correct course of action is to just\n> repack the repository.  (It rarely is, btw.)  You could make things\n> worse if a packfile contains a corrupt object and you have the\n> same valid loose object; a gc would delete the valid object and\n> keep the corrupt one.\n\nOK, my statement is a little blown-out-of-proportion.  Its pretty\nhard these days to corrupt an object within a packfile such that\nwe'll be able to reuse it during the repack that goes on in git-gc,\nbut still actually have it be corrupt enough that the object is\nuseless.  The recent index version 2 work from Nico makes it even\nharder, as the index adds an additional checksum over the entire\nobject header and body.\n\nBut still, even though the risk is pretty small, I think that\nrunning a destructive operation like git-gc in a repository that is\nnot acting normally is a bad idea.  You should try to diagnose and\ncorrect the issue before making further changes (or reorganizations)\nto that repository's contents.\n\n-- \nShawn.\n"},{"id":"41469","messageId":"alpine.LFD.0.99.0705081140000.24220@xanadu.home","threadId":"8033","inReplyTo":"17984.35097.568689.482933@lisa.zopyra.com","subject":"Re: git pull failure, truncated object","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-05-08T15:41:14Z","receivedAt":"2007-05-08T15:41:14Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 8 May 2007, Bill Lear wrote:\n\n> He did a git-gc, twice, and retried.  Still failed.\n> \n> So, he called me in and we tried to see if the server was acting up\n> --- perhaps an NFS problem, as we've had those before, but got very\n> different error messages.  Watched the log file from git-daemon, and\n> saw nothing.  Finally we took a look at the local repos\n> .git/objects/4b, and 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d was of\n> length 0.\n> \n> So, I looked in the man page of git-gc and thought to try --prune,\n> as this was not an active repository.  This worked, and then\n> the pull did as well.\n> \n> I'm wondering why git-gc did not at least warn us of this problem when\n> we tried it.  It appeared to us that git-gc gave our repo a clean bill\n> of health, and so we turned our attention to the remote and\n> investigated there, instead of continuing in the local repo.\n\ngit-gc != git-fsck.\n\n\nNicolas\n"},{"id":"41470","messageId":"17984.39776.771508.873437@lisa.zopyra.com","threadId":"8033","inReplyTo":"alpine.LFD.0.99.0705081140000.24220@xanadu.home","subject":"Re: git pull failure, truncated object","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-05-08T15:46:40Z","receivedAt":"2007-05-08T15:46:40Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Tuesday, May 8, 2007 at 11:41:14 (-0400) Nicolas Pitre writes:\n>On Tue, 8 May 2007, Bill Lear wrote:\n>\n>> He did a git-gc, twice, and retried.  Still failed.\n>> \n>> So, he called me in and we tried to see if the server was acting up\n>> --- perhaps an NFS problem, as we've had those before, but got very\n>> different error messages.  Watched the log file from git-daemon, and\n>> saw nothing.  Finally we took a look at the local repos\n>> .git/objects/4b, and 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d was of\n>> length 0.\n>> \n>> So, I looked in the man page of git-gc and thought to try --prune,\n>> as this was not an active repository.  This worked, and then\n>> the pull did as well.\n>> \n>> I'm wondering why git-gc did not at least warn us of this problem when\n>> we tried it.  It appeared to us that git-gc gave our repo a clean bill\n>> of health, and so we turned our attention to the remote and\n>> investigated there, instead of continuing in the local repo.\n>\n>git-gc != git-fsck.\n\nIndeed, as is now clear to me.  Would it be prudent to have git-gc\nrun a quick git-fsck internally and warn if things are not in a kosher\nstate?\n\n\nBill\n"},{"id":"41480","messageId":"alpine.LFD.0.99.0705081336020.24220@xanadu.home","threadId":"8033","inReplyTo":"17984.39776.771508.873437@lisa.zopyra.com","subject":"Re: git pull failure, truncated object","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-05-08T17:51:57Z","receivedAt":"2007-05-08T17:51:57Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 8 May 2007, Bill Lear wrote:\n\n> On Tuesday, May 8, 2007 at 11:41:14 (-0400) Nicolas Pitre writes:\n> >On Tue, 8 May 2007, Bill Lear wrote:\n> >\n> >> He did a git-gc, twice, and retried.  Still failed.\n> >> \n> >> So, he called me in and we tried to see if the server was acting up\n> >> --- perhaps an NFS problem, as we've had those before, but got very\n> >> different error messages.  Watched the log file from git-daemon, and\n> >> saw nothing.  Finally we took a look at the local repos\n> >> .git/objects/4b, and 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d was of\n> >> length 0.\n> >> \n> >> So, I looked in the man page of git-gc and thought to try --prune,\n> >> as this was not an active repository.  This worked, and then\n> >> the pull did as well.\n> >> \n> >> I'm wondering why git-gc did not at least warn us of this problem when\n> >> we tried it.  It appeared to us that git-gc gave our repo a clean bill\n> >> of health, and so we turned our attention to the remote and\n> >> investigated there, instead of continuing in the local repo.\n> >\n> >git-gc != git-fsck.\n> \n> Indeed, as is now clear to me.  Would it be prudent to have git-gc\n> run a quick git-fsck internally and warn if things are not in a kosher\n> state?\n\nNo.  git-fsck is a potentially expensive operation and it is up to you \nto remember that git-gc isn't about repository sanity. git-gc only \nrepacks things and if it encounters an object that is corrupt it will \nabort and leave your object store as is.  In your case the corrupted \nobject wasn't one that needed to be repacked which explains why git-gc \nsucceeded.\n\n\nNicolas\n"}]}