From 2ab2b1f9e2b4c5f4910383525daf4752eac2eb40 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 4 May 2020 13:25:10 -0400 Subject: [PATCH] comment --- ..._6a512ab2d6ea583a1913c9837e953760._comment | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 doc/forum/Repair_in_steps__63__/comment_1_6a512ab2d6ea583a1913c9837e953760._comment diff --git a/doc/forum/Repair_in_steps__63__/comment_1_6a512ab2d6ea583a1913c9837e953760._comment b/doc/forum/Repair_in_steps__63__/comment_1_6a512ab2d6ea583a1913c9837e953760._comment new file mode 100644 index 0000000000..37071f1947 --- /dev/null +++ b/doc/forum/Repair_in_steps__63__/comment_1_6a512ab2d6ea583a1913c9837e953760._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2020-05-04T17:07:55Z" + content=""" +The command uses `git fsck` to get a list of git objects that are missing +from the repository. It then tries to get those objects from remotes. So, +skipping the fsck is not really possible. + +Also in some cases, it may need to fsck again after the initial pass. + +You must have an exceptionally large git repo (and/or slow computer) for git +fsck to take more than several minutes. + +I wonder if passing --connectivity-only to git fsck speeds it up +significantly for you? Actually corrupted blobs are probably much rarer +than blobs that are just missing, so it might be that git annex repair +could optionally use that to run fsck faster. +"""]] -- 2.30.2