@@ -72,30 +72,20 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
72
72
a blob, the contents are written into the file, rather than
73
73
its object name.
74
74
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
+ ----------
85
77
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).
90
84
91
85
Any corrupt objects you will have to find in backups or other archives
92
86
(i.e., you can just remove them and do an 'rsync' with some other site in
93
87
the hopes that somebody else has the object you have corrupted).
94
88
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
-
99
89
Extracted Diagnostics
100
90
---------------------
101
91
0 commit comments