"Marco Costalba" <mcostalba@xxxxxxxxx> writes:
>> This is totally untested, but maybe something like this?
>
> It works for me. Just some trailing white space warning when applying.
The change only removes the error message without changing any
other logic, so if that works for you, I wonder if leaving
things as they are is a better option than doing anything short
of implementing an AI that tries to pattern-match the "allegedly
corrupt file" with "sorry no such page found" in many natural
languages.
My test patch makes it impossible to track down the real
breakage when an HTTP-reachable repository _does_ have a corrupt
object.
So how about doing this instead?
-- >8 --
diff --git a/http-fetch.c b/http-fetch.c
index 8fd9de0..1405c1f 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -8,6 +8,7 @@
#define RANGE_HEADER_SIZE 30
static int got_alternates = -1;
+static int corrupt_object_found = 0;
static struct curl_slist *no_pragma_header;
@@ -830,6 +831,7 @@ static int fetch_object(struct alt_base
obj_req->errorstr, obj_req->curl_result,
obj_req->http_code, hex);
} else if (obj_req->zret != Z_STREAM_END) {
+ corrupt_object_found++;
ret = error("File %s (%s) corrupt", hex, obj_req->url);
} else if (memcmp(obj_req->sha1, obj_req->real_sha1, 20)) {
ret = error("File %s has bad hash", hex);
@@ -989,5 +991,11 @@ int main(int argc, char **argv)
http_cleanup();
+ if (corrupt_object_found) {
+ fprintf(stderr,
+"Some loose object were found to be corrupt, but they might be just\n"
+"a false '404 Not Found' error message sent with incorrect HTTP\n"
+"status code. Suggest running git fsck-objects.\n");
+ }
return rc;
}
-
: 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