summaryrefslogtreecommitdiff
path: root/builtin-ls-files.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@osdl.org>2007-01-11 22:09:31 (GMT)
committerJunio C Hamano <junkio@cox.net>2007-01-11 22:44:17 (GMT)
commit9130ac1e1966adb9922e64f645730d0d45383495 (patch)
treefa442a758f86f26e26621a93ad94f2fa84b05982 /builtin-ls-files.c
parent93c1e07947e83f13fa8f1c89cb4897b5c71459ff (diff)
downloadgit-9130ac1e1966adb9922e64f645730d0d45383495.zip
git-9130ac1e1966adb9922e64f645730d0d45383495.tar.gz
git-9130ac1e1966adb9922e64f645730d0d45383495.tar.bz2
Better error messages for corrupt databases
This fixes another problem that Andy's case showed: git-fsck-objects reports nonsensical results for corrupt objects. There were actually two independent and confusing problems: - when we had a zero-sized file and used map_sha1_file, mmap() would return EINVAL, and git-fsck-objects would report that as an insane and confusing error. I don't know when this was introduced, it might have been there forever. - when "parse_object()" returned NULL, fsck would say "object not found", which can be very confusing, since obviously the object might "exist", it's just unparseable because it's totally corrupt. So this just makes "xmmap()" return NULL for a zero-sized object (which is a valid thing pointer, exactly the same way "malloc()" can return NULL for a zero-sized allocation). That fixes the first problem (but we could have fixed it in the caller too - I don't personally much care whichever way it goes, but maybe somebody should check that the NO_MMAP case does something sane in this case too?). And the second problem is solved by just making the error message slightly clearer - the failure to parse an object may be because it's missing or corrupt, not necessarily because it's not "found". Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'builtin-ls-files.c')
0 files changed, 0 insertions, 0 deletions