On Thu, Nov 21, 2013 at 12:04:26PM -0400, Joey Hess wrote: > Jeff King wrote: > > This latter behavior is much worse for two reasons. One, > > git reports an allocation error when the real error is > > corruption. And two, the program dies unconditionally, so > > you cannot even run fsck (which would otherwise ignore the > > broken object and keep going). > > BTW, I've also seen git cat-file --batch report wrong sizes for objects, > sometimes without crashing. This is particularly problimatic because if > the object size is wrong, it's very hard to detect the actual end of the > object output in the batch mode stream. Hrm. For --batch, I'd think we would open the whole object and notice the corruption, even with the current code. But for --batch-check, we use sha1_object_info, and for an "experimental" object, we do not need to de-zlib the object at all. So we end up reporting whatever crap we decipher from the garbage bytes. My patch would fix that, as we would not incorrectly guess an object is experimental anymore. If you have specific cases that trigger even after my patch, I'd be interested to see them. -Peff -- 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