Jeff King <peff@xxxxxxxx> writes: > So we can simplify things by bailing immediately in read_loose_object() > when we encounter an unknown type. This has a few user-visible effects: > > a. Instead of producing a single line of error output like this: > > error: 26ed13ce3564fbbb44e35bde42c7da717ea004a6: object is of unknown type 'bogus': .git/objects/26/ed13ce3564fbbb44e35bde42c7da717ea004a6 > > we'll now issue two lines (the first from read_loose_object() when > we see the unparsable header, and the second from the fsck code, > since we couldn't read the object): > > error: unable to parse type from header 'bogus 4' of .git/objects/26/ed13ce3564fbbb44e35bde42c7da717ea004a6 > error: 26ed13ce3564fbbb44e35bde42c7da717ea004a6: object corrupt or missing: .git/objects/26/ed13ce3564fbbb44e35bde42c7da717ea004a6 Just curious; is the difference between 'bogus' and 'bogus 4' significant in the above examples? > > This is a little more verbose, but this sort of error should be > rare (such objects are almost impossible to work with, and cannot > be transferred between repositories as they are not representable > in packfiles). And as a bonus, reporting the broken header in full > could help with debugging other cases (e.g., a header like "blob > xyzzy\0" would fail in parsing the size, but previously we'd not > have showed the offending bytes). Yup, I do not think anybody minds the message that has overly long object name toward the end, instead of the beginning, of line, either. > b. An object with an unknown type will be reported as corrupt, without > actually doing a hash check. Again, I think this is unlikely to > matter in practice since such objects are totally unusable. Agreed. > We'll update one fsck test to match the new error strings. And we can > remove another test that covered the case of an object with an unknown > type _and_ a hash corruption. Since we'll skip the hash check now in > this case, the test is no longer interesting. > > Signed-off-by: Jeff King <peff@xxxxxxxx> > --- > builtin/fsck.c | 13 ++----------- > object-file.c | 12 +++++++++--- > t/t1450-fsck.sh | 29 +++-------------------------- > 3 files changed, 14 insertions(+), 40 deletions(-) Pleasant. Thanks.
