Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
> At the moment, the git-fsck's integrity checks are targeted toward the
> end user, i.e. the error messages are really just messages, intended for
> human consumption.
>
> Under certain circumstances, some of those errors should be allowed to
> be turned into mere warnings, though, because the cost of fixing the
> issues might well be larger than the cost of carrying those flawed
> objects.
> Interdiff below the diffstat. It's huge. Sorry.
Heh, no need to say sorry, though. A large interdiff means you did
a lot more work, after all.
I haven't had a chance to go through the all the patches, but one
thing I noticed that did not appear in the interdiff is that some of
the message IDs are unclear. For example, there are BAD_something,
INVALID_something and MISSING_something. The last one is in a
different category and is good, but how are the former two
differenciated? Do they follow some systematic rules, or they are
named after the way how they happened to be reported in the original
textual error message?
Some of the questionable groups are:
BAD_DATE DATE_OVERFLOW
BAD_TREE_SHA1 INVALID_OBJECT_SHA1 INVALID_TREE
BAD_PARENT_SHA1 INVALID_OBJECT_SHA1
Also it is unclear if NOT_SORTED is to be used ever for any error
other than a tree object sorted incorrectly, or if we start noticing
a new error that something is not sorted, we will reuse this one.
I also briefly wondered if fsck.skipList should be finer grained
than "these are know to be broken, do not bother reporting problems
with them" (e.g. I know v0.99 lacks "tagger" so I want to squelch
MISSING_TAGGER_ENTRY for it, but I want to be notified on any other
errors). But that only matters if we update Git to a version with a
new fsck that knows yet more kinds of breakages, so it is not a huge
issue, and the simplicity of "be silent on these objects" is
probably better overall.
Thanks.
--
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