]> git.ipfire.org Git - thirdparty/git.git/blame - Documentation/git-fsck-cache.txt
[PATCH 1/4] split core-git.txt and update
[thirdparty/git.git] / Documentation / git-fsck-cache.txt
CommitLineData
2cf565c5
DG
1git-fsck-cache(1)
2=================
3v0.1, May 2005
4
5NAME
6----
7git-fsck-cache - Verifies the connectivity and validity of the objects in the database
8
9
10SYNOPSIS
11--------
12'git-fsck-cache' [--tags] [--root] [[--unreachable] [--cache] <object>\*]
13
14DESCRIPTION
15-----------
16Verifies the connectivity and validity of the objects in the database.
17
18OPTIONS
19-------
20<object>::
21 An object to treat as the head of an unreachability trace.
22
23--unreachable::
24 Print out objects that exist but that aren't readable from any
25 of the specified head nodes.
26
27--root::
28 Report root nodes.
29
30--tags::
31 Report tags.
32
33--cache::
34 Consider any object recorded in the cache also as a head node for
35 an unreachability trace.
36
37It tests SHA1 and general object sanity, and it does full tracking of
38the resulting reachability and everything else. It prints out any
39corruption it finds (missing or bad objects), and if you use the
40'--unreachable' flag it will also print out objects that exist but
41that aren't readable from any of the specified head nodes.
42
43So for example
44
45 git-fsck-cache --unreachable $(cat .git/HEAD)
46
47or, for Cogito users:
48
49 git-fsck-cache --unreachable $(cat .git/refs/heads/*)
50
51will do quite a _lot_ of verification on the tree. There are a few
52extra validity tests to be added (make sure that tree objects are
53sorted properly etc), but on the whole if "git-fsck-cache" is happy, you
54do have a valid tree.
55
56Any corrupt objects you will have to find in backups or other archives
57(ie you can just remove them and do an "rsync" with some other site in
58the hopes that somebody else has the object you have corrupted).
59
60Of course, "valid tree" doesn't mean that it wasn't generated by some
61evil person, and the end result might be crap. Git is a revision
62tracking system, not a quality assurance system ;)
63
64Extracted Diagnostics
65---------------------
66
67expect dangling commits - potential heads - due to lack of head information::
68 You haven't specified any nodes as heads so it won't be
69 possible to differentiate between un-parented commits and
70 root nodes.
71
72missing sha1 directory '<dir>'::
73 The directory holding the sha1 objects is missing.
74
75unreachable <type> <object>::
76 The <type> object <object>, isn't actually referred to directly
77 or indirectly in any of the trees or commits seen. This can
78 mean that there's another root node that you're not specifying
79 or that the tree is corrupt. If you haven't missed a root node
80 then you might as well delete unreachable nodes since they
81 can't be used.
82
83missing <type> <object>::
84 The <type> object <object>, is referred to but isn't present in
85 the database.
86
87dangling <type> <object>::
88 The <type> object <object>, is present in the database but never
89 'directly' used. A dangling commit could be a root node.
90
91warning: git-fsck-cache: tree <tree> has full pathnames in it::
92 And it shouldn't...
93
94sha1 mismatch <object>::
95 The database has an object who's sha1 doesn't match the
96 database value.
97 This indicates a serious data integrity problem.
98 (note: this error occured during early git development when
99 the database format changed.)
100
101Environment Variables
102---------------------
103
104GIT_OBJECT_DIRECTORY::
105 used to specify the object database root (usually .git/objects)
106
107GIT_INDEX_FILE::
108 used to specify the cache
109
110
111Author
112------
113Written by Linus Torvalds <torvalds@osdl.org>
114
115Documentation
116--------------
117Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
118
119GIT
120---
121Part of the link:git.html[git] suite
122