1git-fsck(1) 2=========== 3 4NAME 5---- 6git-fsck - Verifies the connectivity and validity of the objects in the database 7 8 9SYNOPSIS 10-------- 11[verse] 12'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] 13 [--full] [--strict] [--verbose] [--lost-found] [<object>*] 14 15DESCRIPTION 16----------- 17Verifies the connectivity and validity of the objects in the database. 18 19OPTIONS 20------- 21<object>:: 22 An object to treat as the head of an unreachability trace. 23+ 24If no objects are given, git-fsck defaults to using the 25index file and all SHA1 references in .git/refs/* as heads. 26 27--unreachable:: 28 Print out objects that exist but that aren't readable from any 29 of the reference nodes. 30 31--root:: 32 Report root nodes. 33 34--tags:: 35 Report tags. 36 37--cache:: 38 Consider any object recorded in the index also as a head node for 39 an unreachability trace. 40 41--no-reflogs:: 42 Do not consider commits that are referenced only by an 43 entry in a reflog to be reachable. This option is meant 44 only to search for commits that used to be in a ref, but 45 now aren't, but are still in that corresponding reflog. 46 47--full:: 48 Check not just objects in GIT_OBJECT_DIRECTORY 49 ($GIT_DIR/objects), but also the ones found in alternate 50 object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES 51 or $GIT_DIR/objects/info/alternates, 52 and in packed git archives found in $GIT_DIR/objects/pack 53 and corresponding pack subdirectories in alternate 54 object pools. 55 56--strict:: 57 Enable more strict checking, namely to catch a file mode 58 recorded with g+w bit set, which was created by older 59 versions of git. Existing repositories, including the 60 Linux kernel, git itself, and sparse repository have old 61 objects that triggers this check, but it is recommended 62 to check new projects with this flag. 63 64--verbose:: 65 Be chatty. 66 67--lost-found:: 68 Write dangling refs into .git/lost-found/commit/ or 69 .git/lost-found/other/, depending on type. 70 71It tests SHA1 and general object sanity, and it does full tracking of 72the resulting reachability and everything else. It prints out any 73corruption it finds (missing or bad objects), and if you use the 74'--unreachable' flag it will also print out objects that exist but 75that aren't readable from any of the specified head nodes. 76 77So for example 78 79 git-fsck --unreachable HEAD $(cat .git/refs/heads/*) 80 81will do quite a _lot_ of verification on the tree. There are a few 82extra validity tests to be added (make sure that tree objects are 83sorted properly etc), but on the whole if "git-fsck" is happy, you 84do have a valid tree. 85 86Any corrupt objects you will have to find in backups or other archives 87(i.e., you can just remove them and do an "rsync" with some other site in 88the hopes that somebody else has the object you have corrupted). 89 90Of course, "valid tree" doesn't mean that it wasn't generated by some 91evil person, and the end result might be crap. git is a revision 92tracking system, not a quality assurance system ;) 93 94Extracted Diagnostics 95--------------------- 96 97expect dangling commits - potential heads - due to lack of head information:: 98 You haven't specified any nodes as heads so it won't be 99 possible to differentiate between un-parented commits and 100 root nodes. 101 102missing sha1 directory '<dir>':: 103 The directory holding the sha1 objects is missing. 104 105unreachable <type> <object>:: 106 The <type> object <object>, isn't actually referred to directly 107 or indirectly in any of the trees or commits seen. This can 108 mean that there's another root node that you're not specifying 109 or that the tree is corrupt. If you haven't missed a root node 110 then you might as well delete unreachable nodes since they 111 can't be used. 112 113missing <type> <object>:: 114 The <type> object <object>, is referred to but isn't present in 115 the database. 116 117dangling <type> <object>:: 118 The <type> object <object>, is present in the database but never 119 'directly' used. A dangling commit could be a root node. 120 121warning: git-fsck: tree <tree> has full pathnames in it:: 122 And it shouldn't... 123 124sha1 mismatch <object>:: 125 The database has an object who's sha1 doesn't match the 126 database value. 127 This indicates a serious data integrity problem. 128 129Environment Variables 130--------------------- 131 132GIT_OBJECT_DIRECTORY:: 133 used to specify the object database root (usually $GIT_DIR/objects) 134 135GIT_INDEX_FILE:: 136 used to specify the index file of the index 137 138GIT_ALTERNATE_OBJECT_DIRECTORIES:: 139 used to specify additional object database roots (usually unset) 140 141Author 142------ 143Written by Linus Torvalds <torvalds@osdl.org> 144 145Documentation 146-------------- 147Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. 148 149GIT 150--- 151Part of the gitlink:git[7] suite