Skip to content

Commit 2830308

Browse files
peffgitster
authored andcommitted
docs: brush up obsolete bits of git-fsck manpage
After the description and options, the fsck manpage contains some discussion about what it does. Over time, this discussion has become somewhat obsolete, both in content and formatting. In particular: 1. There are many options now, so starting the discussion with "It tests..." makes it unclear whether we are talking about the last option, or about the tool in general. Let's start a new "discussion" section and make our antecedent more clear. 2. It gave an example for --unreachable using for-each-ref to mention all of the heads, saying that it will do "a _lot_ of verification". This is hopelessly out-of-date, as giving no arguments will check much more (reflogs, the index, non-head refs). 3. It goes on to mention tests "to be added" (like tree object sorting). We now have these tests. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 7b6c583 commit 2830308

File tree

1 file changed

+8
-18
lines changed

1 file changed

+8
-18
lines changed

Documentation/git-fsck.txt

Lines changed: 8 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -72,30 +72,20 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
7272
a blob, the contents are written into the file, rather than
7373
its object name.
7474

75-
It tests SHA1 and general object sanity, and it does full tracking of
76-
the resulting reachability and everything else. It prints out any
77-
corruption it finds (missing or bad objects), and if you use the
78-
'--unreachable' flag it will also print out objects that exist but
79-
that aren't reachable from any of the specified head nodes.
80-
81-
So for example
82-
83-
git fsck --unreachable HEAD \
84-
$(git for-each-ref --format="%(objectname)" refs/heads)
75+
DISCUSSION
76+
----------
8577

86-
will do quite a _lot_ of verification on the tree. There are a few
87-
extra validity tests to be added (make sure that tree objects are
88-
sorted properly etc), but on the whole if 'git fsck' is happy, you
89-
do have a valid tree.
78+
git-fsck tests SHA1 and general object sanity, and it does full tracking
79+
of the resulting reachability and everything else. It prints out any
80+
corruption it finds (missing or bad objects), and if you use the
81+
'--unreachable' flag it will also print out objects that exist but that
82+
aren't reachable from any of the specified head nodes (or the default
83+
set, as mentioned above).
9084

9185
Any corrupt objects you will have to find in backups or other archives
9286
(i.e., you can just remove them and do an 'rsync' with some other site in
9387
the hopes that somebody else has the object you have corrupted).
9488

95-
Of course, "valid tree" doesn't mean that it wasn't generated by some
96-
evil person, and the end result might be crap. git is a revision
97-
tracking system, not a quality assurance system ;)
98-
9989
Extracted Diagnostics
10090
---------------------
10191

0 commit comments

Comments
 (0)