Hi Junio,
On 2015-06-22 06:21, Junio C Hamano wrote:
On Fri, Jun 19, 2015 at 6:35 AM, Johannes Schindelin
[off-list ref] wrote:
quoted
@@ -227,6 +277,10 @@ static int report(struct fsck_options *options, struct object *object,
if (msg_type == FSCK_IGNORE)
return 0;
+ if (options->skiplist && object &&
+ sha1_array_lookup(options->skiplist, object->sha1) >= 0)
+ return 0;
+
if (msg_type == FSCK_FATAL)
msg_type = FSCK_ERROR;
else if (msg_type == FSCK_INFO)
I just double checked this patch because I wanted to make sure this
was applied in the
report() function (i.e. behave as if FSCK_IGNORE was specified for
specific objects on
the skip list), and I am happy to see that it indeed is the case.
That was because I briefly feared that skip could be done before going
through the usual
verification chain, which would have been very wrong (e.g. we may want
not to hear about
missing tagger in v2.6.11-tree tag, but nevertheless we would want to
check all the tree
contents pointed at by that tag, as that tree may not be reachable by
any other way).
To be honest, an earlier iteration actually did have that test much earlier in the call chain, but I had changed it to the current location in v5.
My rationale was slightly different from yours: I wanted to affect the performance as little as possible. So looking up each and every object in the skip list (which I expect to be relatively small) seemed to be wasteful. And then it occurred to me that it would make much more sense to just make the skip-list functionality equivalent to the "ignore" message type.
It just occurred to me, however, that one thing is possibly surprising with either version of the skip list functionality: if a certain object is corrupt on disk, it cannot be skipped via the skip-list, as the object is *still* unpacked (which would fail in the case of a corrupt object).
I will document that in the man page.
Ciao,
Dscho