index 9846c859cf3f4c76525aae124e0ef516fa55779f..6fe9484da325fa1f72809937df263574ffe6fb9b 100644 (file)
SYNOPSIS
--------
[verse]
SYNOPSIS
--------
[verse]
-'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--full] [--strict] [--verbose] [--lost-found] [<object>*]
+'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+ [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
DESCRIPTION
-----------
DESCRIPTION
-----------
<object>::
An object to treat as the head of an unreachability trace.
+
<object>::
An object to treat as the head of an unreachability trace.
+
-If no objects are given, git-fsck defaults to using the
+If no objects are given, 'git-fsck' defaults to using the
index file, all SHA1 references in .git/refs/*, and all reflogs (unless
--no-reflogs is given) as heads.
index file, all SHA1 references in .git/refs/*, and all reflogs (unless
--no-reflogs is given) as heads.
or $GIT_DIR/objects/info/alternates,
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
or $GIT_DIR/objects/info/alternates,
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
- object pools.
+ object pools. This is now default; you can turn it off
+ with --no-full.
--strict::
Enable more strict checking, namely to catch a file mode
--strict::
Enable more strict checking, namely to catch a file mode
So for example
So for example
- git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
+ git fsck --unreachable HEAD \
+ $(git for-each-ref --format="%(objectname)" refs/heads)
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
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
+sorted properly etc), but on the whole if 'git-fsck' is happy, you
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
do have a valid tree.
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
+(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some