path: root/Documentation/git-fsck-cache.txt
diff options
Diffstat (limited to 'Documentation/git-fsck-cache.txt')
1 files changed, 122 insertions, 0 deletions
diff --git a/Documentation/git-fsck-cache.txt b/Documentation/git-fsck-cache.txt
new file mode 100644
index 0000000..bcd3b0a
--- /dev/null
+++ b/Documentation/git-fsck-cache.txt
@@ -0,0 +1,122 @@
+v0.1, May 2005
+git-fsck-cache - Verifies the connectivity and validity of the objects in the database
+'git-fsck-cache' [--tags] [--root] [[--unreachable] [--cache] <object>\*]
+Verifies the connectivity and validity of the objects in the database.
+ An object to treat as the head of an unreachability trace.
+ Print out objects that exist but that aren't readable from any
+ of the specified head nodes.
+ Report root nodes.
+ Report tags.
+ Consider any object recorded in the cache also as a head node for
+ an unreachability trace.
+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 readable from any of the specified head nodes.
+So for example
+ git-fsck-cache --unreachable $(cat .git/HEAD)
+or, for Cogito users:
+ git-fsck-cache --unreachable $(cat .git/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
+sorted properly etc), but on the whole if "git-fsck-cache" is happy, you
+do have a valid tree.
+Any corrupt objects you will have to find in backups or other archives
+(ie 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
+evil person, and the end result might be crap. Git is a revision
+tracking system, not a quality assurance system ;)
+Extracted Diagnostics
+expect dangling commits - potential heads - due to lack of head information::
+ You haven't specified any nodes as heads so it won't be
+ possible to differentiate between un-parented commits and
+ root nodes.
+missing sha1 directory '<dir>'::
+ The directory holding the sha1 objects is missing.
+unreachable <type> <object>::
+ The <type> object <object>, isn't actually referred to directly
+ or indirectly in any of the trees or commits seen. This can
+ mean that there's another root node that you're not specifying
+ or that the tree is corrupt. If you haven't missed a root node
+ then you might as well delete unreachable nodes since they
+ can't be used.
+missing <type> <object>::
+ The <type> object <object>, is referred to but isn't present in
+ the database.
+dangling <type> <object>::
+ The <type> object <object>, is present in the database but never
+ 'directly' used. A dangling commit could be a root node.
+warning: git-fsck-cache: tree <tree> has full pathnames in it::
+ And it shouldn't...
+sha1 mismatch <object>::
+ The database has an object who's sha1 doesn't match the
+ database value.
+ This indicates a serious data integrity problem.
+ (note: this error occured during early git development when
+ the database format changed.)
+Environment Variables
+ used to specify the object database root (usually .git/objects)
+ used to specify the cache
+Written by Linus Torvalds <>
+Documentation by David Greaves, Junio C Hamano and the git-list <>.
+Part of the link:git.html[git] suite