Re: fsck option to remove corrupt objects - why/why not?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. :)
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]