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