1GIT-FSCK(1) Git Manual GIT-FSCK(1)
2
3
4
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 [--[no-]full] [--strict] [--verbose] [--lost-found]
12 [--[no-]dangling] [--[no-]progress] [--connectivity-only]
13 [--[no-]name-objects] [<object>*]
14
15
17 Verifies the connectivity and validity of the objects in the database.
18
20 <object>
21 An object to treat as the head of an unreachability trace.
22
23 If no objects are given, git fsck defaults to using the index file,
24 all SHA-1 references in refs namespace, and all reflogs (unless
25 --no-reflogs is given) as heads.
26
27 --unreachable
28 Print out objects that exist but that aren’t reachable from any of
29 the reference nodes.
30
31 --[no-]dangling
32 Print objects that exist but that are never directly used
33 (default). --no-dangling can be used to omit this information from
34 the output.
35
36 --root
37 Report root nodes.
38
39 --tags
40 Report tags.
41
42 --cache
43 Consider any object recorded in the index also as a head node for
44 an unreachability trace.
45
46 --no-reflogs
47 Do not consider commits that are referenced only by an entry in a
48 reflog to be reachable. This option is meant only to search for
49 commits that used to be in a ref, but now aren’t, but are still in
50 that corresponding reflog.
51
52 --full
53 Check not just objects in GIT_OBJECT_DIRECTORY ($GIT_DIR/objects),
54 but also the ones found in alternate object pools listed in
55 GIT_ALTERNATE_OBJECT_DIRECTORIES or
56 $GIT_DIR/objects/info/alternates, and in packed Git archives found
57 in $GIT_DIR/objects/pack and corresponding pack subdirectories in
58 alternate object pools. This is now default; you can turn it off
59 with --no-full.
60
61 --connectivity-only
62 Check only the connectivity of reachable objects, making sure that
63 any objects referenced by a reachable tag, commit, or tree is
64 present. This speeds up the operation by avoiding reading blobs
65 entirely (though it does still check that referenced blobs exist).
66 This will detect corruption in commits and trees, but not do any
67 semantic checks (e.g., for format errors). Corruption in blob
68 objects will not be detected at all.
69
70 Unreachable tags, commits, and trees will also be accessed to find
71 the tips of dangling segments of history. Use --no-dangling if you
72 don’t care about this output and want to speed it up further.
73
74 --strict
75 Enable more strict checking, namely to catch a file mode recorded
76 with g+w bit set, which was created by older versions of Git.
77 Existing repositories, including the Linux kernel, Git itself, and
78 sparse repository have old objects that triggers this check, but it
79 is recommended to check new projects with this flag.
80
81 --verbose
82 Be chatty.
83
84 --lost-found
85 Write dangling objects into .git/lost-found/commit/ or
86 .git/lost-found/other/, depending on type. If the object is a blob,
87 the contents are written into the file, rather than its object
88 name.
89
90 --name-objects
91 When displaying names of reachable objects, in addition to the
92 SHA-1 also display a name that describes how they are reachable,
93 compatible with git-rev-parse(1), e.g.
94 HEAD@{1234567890}~25^2:src/.
95
96 --[no-]progress
97 Progress status is reported on the standard error stream by default
98 when it is attached to a terminal, unless --no-progress or
99 --verbose is specified. --progress forces progress status even if
100 the standard error stream is not directed to a terminal.
101
103 fsck.<msg-id>
104 During fsck git may find issues with legacy data which wouldn’t be
105 generated by current versions of git, and which wouldn’t be sent
106 over the wire if transfer.fsckObjects was set. This feature is
107 intended to support working with legacy repositories containing
108 such data.
109
110 Setting fsck.<msg-id> will be picked up by git-fsck(1), but to
111 accept pushes of such data set receive.fsck.<msg-id> instead, or to
112 clone or fetch it set fetch.fsck.<msg-id>.
113
114 The rest of the documentation discusses fsck.* for brevity, but
115 the same applies for the corresponding receive.fsck.* and
116 fetch.<msg-id>.*. variables.
117
118 Unlike variables like color.ui and core.editor the
119 receive.fsck.<msg-id> and fetch.fsck.<msg-id> variables will not
120 fall back on the fsck.<msg-id> configuration if they aren’t set. To
121 uniformly configure the same fsck settings in different
122 circumstances all three of them they must all set to the same
123 values.
124
125 When fsck.<msg-id> is set, errors can be switched to warnings and
126 vice versa by configuring the fsck.<msg-id> setting where the
127 <msg-id> is the fsck message ID and the value is one of error, warn
128 or ignore. For convenience, fsck prefixes the error/warning with
129 the message ID, e.g. "missingEmail: invalid author/committer line -
130 missing email" means that setting fsck.missingEmail = ignore will
131 hide that issue.
132
133 In general, it is better to enumerate existing objects with
134 problems with fsck.skipList, instead of listing the kind of
135 breakages these problematic objects share to be ignored, as doing
136 the latter will allow new instances of the same breakages go
137 unnoticed.
138
139 Setting an unknown fsck.<msg-id> value will cause fsck to die, but
140 doing the same for receive.fsck.<msg-id> and fetch.fsck.<msg-id>
141 will only cause git to warn.
142
143 fsck.skipList
144 The path to a list of object names (i.e. one unabbreviated SHA-1
145 per line) that are known to be broken in a non-fatal way and should
146 be ignored. On versions of Git 2.20 and later comments (#), empty
147 lines, and any leading and trailing whitespace is ignored.
148 Everything but a SHA-1 per line will error out on older versions.
149
150 This feature is useful when an established project should be
151 accepted despite early commits containing errors that can be safely
152 ignored such as invalid committer email addresses. Note: corrupt
153 objects cannot be skipped with this setting.
154
155 Like fsck.<msg-id> this variable has corresponding
156 receive.fsck.skipList and fetch.fsck.skipList variants.
157
158 Unlike variables like color.ui and core.editor the
159 receive.fsck.skipList and fetch.fsck.skipList variables will not
160 fall back on the fsck.skipList configuration if they aren’t set. To
161 uniformly configure the same fsck settings in different
162 circumstances all three of them they must all set to the same
163 values.
164
165 Older versions of Git (before 2.20) documented that the object
166 names list should be sorted. This was never a requirement, the
167 object names could appear in any order, but when reading the list
168 we tracked whether the list was sorted for the purposes of an
169 internal binary search implementation, which could save itself some
170 work with an already sorted list. Unless you had a humongous list
171 there was no reason to go out of your way to pre-sort the list.
172 After Git version 2.20 a hash implementation is used instead, so
173 there’s now no reason to pre-sort the list.
174
176 git-fsck tests SHA-1 and general object sanity, and it does full
177 tracking of the resulting reachability and everything else. It prints
178 out any corruption it finds (missing or bad objects), and if you use
179 the --unreachable flag it will also print out objects that exist but
180 that aren’t reachable from any of the specified head nodes (or the
181 default set, as mentioned above).
182
183 Any corrupt objects you will have to find in backups or other archives
184 (i.e., you can just remove them and do an rsync with some other site in
185 the hopes that somebody else has the object you have corrupted).
186
187 If core.commitGraph is true, the commit-graph file will also be
188 inspected using git commit-graph verify. See git-commit-graph(1).
189
191 expect dangling commits - potential heads - due to lack of head
192 information
193 You haven’t specified any nodes as heads so it won’t be possible to
194 differentiate between un-parented commits and root nodes.
195
196 missing sha1 directory <dir>
197 The directory holding the sha1 objects is missing.
198
199 unreachable <type> <object>
200 The <type> object <object>, isn’t actually referred to directly or
201 indirectly in any of the trees or commits seen. This can mean that
202 there’s another root node that you’re not specifying or that the
203 tree is corrupt. If you haven’t missed a root node then you might
204 as well delete unreachable nodes since they can’t be used.
205
206 missing <type> <object>
207 The <type> object <object>, is referred to but isn’t present in the
208 database.
209
210 dangling <type> <object>
211 The <type> object <object>, is present in the database but never
212 directly used. A dangling commit could be a root node.
213
214 hash mismatch <object>
215 The database has an object whose hash doesn’t match the object
216 database value. This indicates a serious data integrity problem.
217
219 GIT_OBJECT_DIRECTORY
220 used to specify the object database root (usually $GIT_DIR/objects)
221
222 GIT_INDEX_FILE
223 used to specify the index file of the index
224
225 GIT_ALTERNATE_OBJECT_DIRECTORIES
226 used to specify additional object database roots (usually unset)
227
229 Part of the git(1) suite
230
231
232
233Git 2.24.1 12/10/2019 GIT-FSCK(1)