1git-fsck-cache(1) 2================= 3v0.1, May 2005 4 5NAME 6---- 7git-fsck-cache - Verifies the connectivity and validity of the objects in the database 8 9 10SYNOPSIS 11-------- 12'git-fsck-cache' [--tags] [--root] [--unreachable] [--cache] [<object>*] 13 14DESCRIPTION 15----------- 16Verifies the connectivity and validity of the objects in the database. 17 18OPTIONS 19------- 20<object>:: 21 An object to treat as the head of an unreachability trace. 22 23 If no objects are given, git-fsck-cache defaults to using the 24 index file and all SHA1 references in .git/refs/* as heads. 25 26--unreachable:: 27 Print out objects that exist but that aren't readable from any 28 of the reference nodes. 29 30--root:: 31 Report root nodes. 32 33--tags:: 34 Report tags. 35 36--cache:: 37 Consider any object recorded in the cache also as a head node for 38 an unreachability trace. 39 40It tests SHA1 and general object sanity, and it does full tracking of 41the resulting reachability and everything else. It prints out any 42corruption it finds (missing or bad objects), and if you use the 43'--unreachable' flag it will also print out objects that exist but 44that aren't readable from any of the specified head nodes. 45 46So for example 47 48 git-fsck-cache --unreachable $(cat .git/HEAD) 49 50or, for Cogito users: 51 52 git-fsck-cache --unreachable $(cat .git/refs/heads/*) 53 54will do quite a _lot_ of verification on the tree. There are a few 55extra validity tests to be added (make sure that tree objects are 56sorted properly etc), but on the whole if "git-fsck-cache" is happy, you 57do have a valid tree. 58 59Any corrupt objects you will have to find in backups or other archives 60(ie you can just remove them and do an "rsync" with some other site in 61the hopes that somebody else has the object you have corrupted). 62 63Of course, "valid tree" doesn't mean that it wasn't generated by some 64evil person, and the end result might be crap. Git is a revision 65tracking system, not a quality assurance system ;) 66 67Extracted Diagnostics 68--------------------- 69 70expect dangling commits - potential heads - due to lack of head information:: 71 You haven't specified any nodes as heads so it won't be 72 possible to differentiate between un-parented commits and 73 root nodes. 74 75missing sha1 directory '<dir>':: 76 The directory holding the sha1 objects is missing. 77 78unreachable <type> <object>:: 79 The <type> object <object>, isn't actually referred to directly 80 or indirectly in any of the trees or commits seen. This can 81 mean that there's another root node that you're not specifying 82 or that the tree is corrupt. If you haven't missed a root node 83 then you might as well delete unreachable nodes since they 84 can't be used. 85 86missing <type> <object>:: 87 The <type> object <object>, is referred to but isn't present in 88 the database. 89 90dangling <type> <object>:: 91 The <type> object <object>, is present in the database but never 92 'directly' used. A dangling commit could be a root node. 93 94warning: git-fsck-cache: tree <tree> has full pathnames in it:: 95 And it shouldn't... 96 97sha1 mismatch <object>:: 98 The database has an object who's sha1 doesn't match the 99 database value. 100 This indicates a serious data integrity problem. 101 (note: this error occured during early git development when 102 the database format changed.) 103 104Environment Variables 105--------------------- 106 107GIT_OBJECT_DIRECTORY:: 108 used to specify the object database root (usually .git/objects) 109 110GIT_INDEX_FILE:: 111 used to specify the cache 112 113 114Author 115------ 116Written by Linus Torvalds <torvalds@osdl.org> 117 118Documentation 119-------------- 120Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. 121 122GIT 123--- 124Part of the link:git.html[git] suite 125