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