On Thu, Sep 5, 2013 at 11:36 AM, Jeff King <p...@peff.net> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to