On Thu, Oct 16, 2014 at 2:25 PM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Oct 16, 2014 at 11:04:04AM +0200, Johan Herland wrote: >> I simply copied the packfile containing the good copy into the >> corrupted repo, and then ran a "git gc", which "happened" to use the >> good copy of the corrupted object and complete successfully (instead >> of barfing on the bad copy). The GC then removed the old >> (now-obsolete) packfiles, and thus the corruption was gone. >> >> However, exactly _why_ git happened to prefer the good copy in my >> copied packfile instead of the bad copy in the existing packfile, I do >> not know. I suspect some amount of pure luck was involved. > > I'm not sure that it is luck, but more like 8eca0b4 (implement some > resilience against pack corruptions, 2008-06-23) working as intended[1]. > Generally, git should be able to warn about corrupted objects and look > in other packs for them (both for regular operations, and for > repacking). > > -Peff > > [1] That's just one of the many commits dealing with this. Try running > "git log --author=Nicolas.Pitre --grep=corrupt" for more. :) Indeed, from reading the logs, it seems what I assumed was a lucky strike, was actually carefully designed behavior. With that in mind, I'm no longer so sure that fsck actually needs an option to remove corrupt objects. Instead, it's probably better to leave the corrupt object in place until a good copy can be located and copied into the repo, at which point Nicolas' brilliant work will make sure a simple repack takes care of fixing the corruption. That said, we should consider documenting this strategy for fixing corruptions: - Locate the a good copy of the affected objects in another repo - Copy relevant pack file or loose object into this repo - Run "git gc" - Profit! ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html