a blob, the contents are written into the file, rather than
its object name.
- It tests SHA1 and general object sanity, and it does full tracking of
- the resulting reachability and everything else. It prints out any
- corruption it finds (missing or bad objects), and if you use the
- '--unreachable' flag it will also print out objects that exist but
- that aren't reachable from any of the specified head nodes.
-
- So for example
-
- git fsck --unreachable HEAD \
- $(git for-each-ref --format="%(objectname)" refs/heads)
+--progress::
+--no-progress::
+ Progress status is reported on the standard error stream by
+ default when it is attached to a terminal, unless
+ --no-progress or --verbose is specified. --progress forces
+ progress status even if the standard error stream is not
+ directed to a terminal.
+
+ DISCUSSION
+ ----------
- will do quite a _lot_ of verification on the tree. There are a few
- extra validity tests to be added (make sure that tree objects are
- sorted properly etc), but on the whole if 'git fsck' is happy, you
- do have a valid tree.
+ git-fsck tests SHA1 and general object sanity, and it does full tracking
+ of the resulting reachability and everything else. It prints out any
+ corruption it finds (missing or bad objects), and if you use the
+ '--unreachable' flag it will also print out objects that exist but that
+ aren't reachable from any of the specified head nodes (or the default
+ set, as mentioned above).
Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an 'rsync' with some other site in