1GIT-FSCK(1)                       Git Manual                       GIT-FSCK(1)
2
3
4

NAME

6       git-fsck - Verifies the connectivity and validity of the objects in the
7       database
8

SYNOPSIS

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

DESCRIPTION

16       Verifies the connectivity and validity of the objects in the database.
17

OPTIONS

19       <object>
20           An object to treat as the head of an unreachability trace.
21
22           If no objects are given, git fsck defaults to using the index file,
23           all SHA-1 references in refs namespace, and all reflogs (unless
24           --no-reflogs is given) as heads.
25
26       --unreachable
27           Print out objects that exist but that aren’t reachable from any of
28           the reference nodes.
29
30       --[no-]dangling
31           Print objects that exist but that are never directly used
32           (default).  --no-dangling can be used to omit this information from
33           the output.
34
35       --root
36           Report root nodes.
37
38       --tags
39           Report tags.
40
41       --cache
42           Consider any object recorded in the index also as a head node for
43           an unreachability trace.
44
45       --no-reflogs
46           Do not consider commits that are referenced only by an entry in a
47           reflog to be reachable. This option is meant only to search for
48           commits that used to be in a ref, but now aren’t, but are still in
49           that corresponding reflog.
50
51       --full
52           Check not just objects in GIT_OBJECT_DIRECTORY ($GIT_DIR/objects),
53           but also the ones found in alternate object pools listed in
54           GIT_ALTERNATE_OBJECT_DIRECTORIES or
55           $GIT_DIR/objects/info/alternates, and in packed Git archives found
56           in $GIT_DIR/objects/pack and corresponding pack subdirectories in
57           alternate object pools. This is now default; you can turn it off
58           with --no-full.
59
60       --connectivity-only
61           Check only the connectivity of reachable objects, making sure that
62           any objects referenced by a reachable tag, commit, or tree is
63           present. This speeds up the operation by avoiding reading blobs
64           entirely (though it does still check that referenced blobs exist).
65           This will detect corruption in commits and trees, but not do any
66           semantic checks (e.g., for format errors). Corruption in blob
67           objects will not be detected at all.
68
69           Unreachable tags, commits, and trees will also be accessed to find
70           the tips of dangling segments of history. Use --no-dangling if you
71           don’t care about this output and want to speed it up further.
72
73       --strict
74           Enable more strict checking, namely to catch a file mode recorded
75           with g+w bit set, which was created by older versions of Git.
76           Existing repositories, including the Linux kernel, Git itself, and
77           sparse repository have old objects that triggers this check, but it
78           is recommended to check new projects with this flag.
79
80       --verbose
81           Be chatty.
82
83       --lost-found
84           Write dangling objects into .git/lost-found/commit/ or
85           .git/lost-found/other/, depending on type. If the object is a blob,
86           the contents are written into the file, rather than its object
87           name.
88
89       --name-objects
90           When displaying names of reachable objects, in addition to the
91           SHA-1 also display a name that describes how they are reachable,
92           compatible with git-rev-parse(1), e.g.
93           HEAD@{1234567890}~25^2:src/.
94
95       --[no-]progress
96           Progress status is reported on the standard error stream by default
97           when it is attached to a terminal, unless --no-progress or
98           --verbose is specified. --progress forces progress status even if
99           the standard error stream is not directed to a terminal.
100

CONFIGURATION

102       fsck.<msg-id>
103           During fsck git may find issues with legacy data which wouldn’t be
104           generated by current versions of git, and which wouldn’t be sent
105           over the wire if transfer.fsckObjects was set. This feature is
106           intended to support working with legacy repositories containing
107           such data.
108
109           Setting fsck.<msg-id> will be picked up by git-fsck(1), but to
110           accept pushes of such data set receive.fsck.<msg-id> instead, or to
111           clone or fetch it set fetch.fsck.<msg-id>.
112
113           The rest of the documentation discusses fsck.*  for brevity, but
114           the same applies for the corresponding receive.fsck.*  and
115           fetch.<msg-id>.*. variables.
116
117           Unlike variables like color.ui and core.editor the
118           receive.fsck.<msg-id> and fetch.fsck.<msg-id> variables will not
119           fall back on the fsck.<msg-id> configuration if they aren’t set. To
120           uniformly configure the same fsck settings in different
121           circumstances all three of them they must all set to the same
122           values.
123
124           When fsck.<msg-id> is set, errors can be switched to warnings and
125           vice versa by configuring the fsck.<msg-id> setting where the
126           <msg-id> is the fsck message ID and the value is one of error, warn
127           or ignore. For convenience, fsck prefixes the error/warning with
128           the message ID, e.g. "missingEmail: invalid author/committer line -
129           missing email" means that setting fsck.missingEmail = ignore will
130           hide that issue.
131
132           In general, it is better to enumerate existing objects with
133           problems with fsck.skipList, instead of listing the kind of
134           breakages these problematic objects share to be ignored, as doing
135           the latter will allow new instances of the same breakages go
136           unnoticed.
137
138           Setting an unknown fsck.<msg-id> value will cause fsck to die, but
139           doing the same for receive.fsck.<msg-id> and fetch.fsck.<msg-id>
140           will only cause git to warn.
141
142       fsck.skipList
143           The path to a list of object names (i.e. one unabbreviated SHA-1
144           per line) that are known to be broken in a non-fatal way and should
145           be ignored. On versions of Git 2.20 and later comments (#), empty
146           lines, and any leading and trailing whitespace is ignored.
147           Everything but a SHA-1 per line will error out on older versions.
148
149           This feature is useful when an established project should be
150           accepted despite early commits containing errors that can be safely
151           ignored such as invalid committer email addresses. Note: corrupt
152           objects cannot be skipped with this setting.
153
154           Like fsck.<msg-id> this variable has corresponding
155           receive.fsck.skipList and fetch.fsck.skipList variants.
156
157           Unlike variables like color.ui and core.editor the
158           receive.fsck.skipList and fetch.fsck.skipList variables will not
159           fall back on the fsck.skipList configuration if they aren’t set. To
160           uniformly configure the same fsck settings in different
161           circumstances all three of them they must all set to the same
162           values.
163
164           Older versions of Git (before 2.20) documented that the object
165           names list should be sorted. This was never a requirement, the
166           object names could appear in any order, but when reading the list
167           we tracked whether the list was sorted for the purposes of an
168           internal binary search implementation, which could save itself some
169           work with an already sorted list. Unless you had a humongous list
170           there was no reason to go out of your way to pre-sort the list.
171           After Git version 2.20 a hash implementation is used instead, so
172           there’s now no reason to pre-sort the list.
173

DISCUSSION

175       git-fsck tests SHA-1 and general object sanity, and it does full
176       tracking of the resulting reachability and everything else. It prints
177       out any corruption it finds (missing or bad objects), and if you use
178       the --unreachable flag it will also print out objects that exist but
179       that aren’t reachable from any of the specified head nodes (or the
180       default set, as mentioned above).
181
182       Any corrupt objects you will have to find in backups or other archives
183       (i.e., you can just remove them and do an rsync with some other site in
184       the hopes that somebody else has the object you have corrupted).
185
186       If core.commitGraph is true, the commit-graph file will also be
187       inspected using git commit-graph verify. See git-commit-graph(1).
188

EXTRACTED DIAGNOSTICS

190       unreachable <type> <object>
191           The <type> object <object>, isn’t actually referred to directly or
192           indirectly in any of the trees or commits seen. This can mean that
193           there’s another root node that you’re not specifying or that the
194           tree is corrupt. If you haven’t missed a root node then you might
195           as well delete unreachable nodes since they can’t be used.
196
197       missing <type> <object>
198           The <type> object <object>, is referred to but isn’t present in the
199           database.
200
201       dangling <type> <object>
202           The <type> object <object>, is present in the database but never
203           directly used. A dangling commit could be a root node.
204
205       hash mismatch <object>
206           The database has an object whose hash doesn’t match the object
207           database value. This indicates a serious data integrity problem.
208

ENVIRONMENT VARIABLES

210       GIT_OBJECT_DIRECTORY
211           used to specify the object database root (usually $GIT_DIR/objects)
212
213       GIT_INDEX_FILE
214           used to specify the index file of the index
215
216       GIT_ALTERNATE_OBJECT_DIRECTORIES
217           used to specify additional object database roots (usually unset)
218

GIT

220       Part of the git(1) suite
221
222
223
224Git 2.30.2                        2021-03-08                       GIT-FSCK(1)
Impressum