First I'd like to thank John Cai for the work of collating the fsck
msg-id, figuring out what to look for is much easier when it's all in
one place.
While looking at git's handling of invalid objects (again) I found out
that several documented fsck diagnostics can not fire — and
furthermore have somewhat debatable diag levels — because they trigger
a parsing error upstream from the fsck code which actually checks the
relevant properties.
Some of them are actually present in t/t1451-fsck-buffer.sh but I'm
not sure if that is relevant in any way.
The testing / checking was done with Git 2.41.
------
emptyName (WARN) A path contains an empty name.
`fsck_tree` ultimately calls `decode_tree_entry` which fails (returns
-1) if the mode is invalid (e.g. the mode is immediately followed by
\0) or the path is empty. In fsck_tree, this translates to a generic
`badTree` error.
Also not sure how relevant that is, but a badTree error yields a lot
of spam e.g. when specifically fsck-ing the broken tree I get:
error: empty filename in tree entry
error in tree {oid}: broken links
error: empty filename in tree entry
error in tree {oid}: badTree: cannot be parsed as a tree
error: empty filename in tree entry
but for the specific error message, this reproduces for every
error which results in a "badTree" (mode is empty, mode is
invalid, oid is too short, oid is too long, tree object is too
short).
It's possible that part of it is an artefact of my test setup e.g. I
get this if I fsck the object specifically (passing its oid to "git
fsck"), asking fsck to check the repository rather than the specific
object seems to remove the last message in the sequence.
missingTree (ERROR) Missing tree line in a commit object.
If a commit has no `tree` line, or a `tree` line which is not 45 bytes
long (excluding newline), fsck reports
error: bogus commit object {oid}
error: {oid}: object could not be parsed: {path}
error: {oid}: object missing
but no missingTree.
badTreeSha1 (ERROR) A tree has an invalid format.
If a commit has a tree line which is 45 bytes long, but the last 40
bytes are not a valid hex string, fsck reports
error: bad tree pointer in commit {oid}
error: {oid}: object could not be parsed: {path}
error: {oid}: object missing
badParentSha1 (ERROR) A commit object has a bad parent sha1.
Here whether the parent line is too short, too long, or not hex, fsck reports
error: bad parents in commit {oid}
error: {oid}: object could not be parsed: {oid}
error: {oid}: object missing
-------
Finally at least one diagnostic seems to have an incomplete documentation:
fullPathname (WARN) A path contains the full path starting with "/"
but the code uses "strchr" on the name, so it checks if the name
contains a "/" anywhere. The message is also not the best:
> contains full pathnames
-------
There is also a minor inconsistency in the authorship date parsing:
0+0000
triggers "zeroPaddedDate", but
1+0000
triggers "badDate".
I assume that is because the code first checks if the date is a 0
followed by a non-space (assuming it's zero-padded), and only after
that does it check if the timestamp is followed by a space.
This is probably too minor an issue to bother complexifying the checker
though.
