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