On Thu, Sep 5, 2013 at 11:36 AM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Sep 05, 2013 at 10:00:39AM -0400, John Szakmeister wrote: > >> I went to clone a repository from GitHub today and discovered >> something interesting: >> >> :: git clone https://github.com/liebke/incanter.git >> Cloning into 'incanter'... >> remote: Counting objects: 10457, done. >> remote: Compressing objects: 100% (3018/3018), done. >> error: object 4946e1ba09ba5655202a7a5d81ae106b08411061:contains >> zero-padded file modes >> fatal: Error in object >> fatal: index-pack failed > > Yep. These were mostly caused by a bug in Grit that is long-fixed. But > the objects remain in many histories. It would have painful to rewrite > them back then, and it would be even more painful now. I guess there's still the other side of the question though. Are these repositories busted in the sense that something no longer works? I doesn't appear to be the case, but I've not used it extensively say I can't say for certain one way or another. In the sense that the content is not strictly compliant, transfer.fsckObjects did its job, but I wonder if fsck needs to be a little more tolerant now (at least with respect to transfer objects)? I can certainly cope with the issue--it's not a problem for me to flip the flag on the command line. I think it'd be nice to have transer.fsckObjects be the default at some point, considering how little people run fsck otherwise and how long these sorts of issues go undiscovered. Issues like the above seem to stand in the way of that happening though. -John -- 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