18d89fe25c
In b6a8d09f6d (gc docs: include the "gc.*" section from "config" in
"gc", 2019-04-07) the "git gc" documentation was made to include the
config/gc.txt in its "CONFIGURATION" section. We do that in several
other places, but "git gc" was the only one with a blurb above the
include to orient the reader.
We don't want readers to carefully scrutinize "git-config(1)" and
"git-gc(1)" looking for discrepancies, instead we should tell them
that the latter includes a part of the former.
This change formalizes that wording in two new templates to be
included, one for the "git gc" case where the entire section is
included from "git-config(1)", and another for when the inclusion of
"git-config(1)" follows discussion unique to that documentation. In
order to use that re-arrange the order of those being discussed in the
"git-merge(1)" documentation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
170 lines
5.4 KiB
Plaintext
170 lines
5.4 KiB
Plaintext
git-fsck(1)
|
|
===========
|
|
|
|
NAME
|
|
----
|
|
git-fsck - Verifies the connectivity and validity of the objects in the database
|
|
|
|
|
|
SYNOPSIS
|
|
--------
|
|
[verse]
|
|
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
|
|
[--[no-]full] [--strict] [--verbose] [--lost-found]
|
|
[--[no-]dangling] [--[no-]progress] [--connectivity-only]
|
|
[--[no-]name-objects] [<object>...]
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
Verifies the connectivity and validity of the objects in the database.
|
|
|
|
OPTIONS
|
|
-------
|
|
<object>::
|
|
An object to treat as the head of an unreachability trace.
|
|
+
|
|
If no objects are given, 'git fsck' defaults to using the
|
|
index file, all SHA-1 references in `refs` namespace, and all reflogs
|
|
(unless --no-reflogs is given) as heads.
|
|
|
|
--unreachable::
|
|
Print out objects that exist but that aren't reachable from any
|
|
of the reference nodes.
|
|
|
|
--[no-]dangling::
|
|
Print objects that exist but that are never 'directly' used (default).
|
|
`--no-dangling` can be used to omit this information from the output.
|
|
|
|
--root::
|
|
Report root nodes.
|
|
|
|
--tags::
|
|
Report tags.
|
|
|
|
--cache::
|
|
Consider any object recorded in the index also as a head node for
|
|
an unreachability trace.
|
|
|
|
--no-reflogs::
|
|
Do not consider commits that are referenced only by an
|
|
entry in a reflog to be reachable. This option is meant
|
|
only to search for commits that used to be in a ref, but
|
|
now aren't, but are still in that corresponding reflog.
|
|
|
|
--full::
|
|
Check not just objects in GIT_OBJECT_DIRECTORY
|
|
($GIT_DIR/objects), but also the ones found in alternate
|
|
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
|
|
or $GIT_DIR/objects/info/alternates,
|
|
and in packed Git archives found in $GIT_DIR/objects/pack
|
|
and corresponding pack subdirectories in alternate
|
|
object pools. This is now default; you can turn it off
|
|
with --no-full.
|
|
|
|
--connectivity-only::
|
|
Check only the connectivity of reachable objects, making sure
|
|
that any objects referenced by a reachable tag, commit, or tree
|
|
is present. This speeds up the operation by avoiding reading
|
|
blobs entirely (though it does still check that referenced blobs
|
|
exist). This will detect corruption in commits and trees, but
|
|
not do any semantic checks (e.g., for format errors). Corruption
|
|
in blob objects will not be detected at all.
|
|
+
|
|
Unreachable tags, commits, and trees will also be accessed to find the
|
|
tips of dangling segments of history. Use `--no-dangling` if you don't
|
|
care about this output and want to speed it up further.
|
|
|
|
--strict::
|
|
Enable more strict checking, namely to catch a file mode
|
|
recorded with g+w bit set, which was created by older
|
|
versions of Git. Existing repositories, including the
|
|
Linux kernel, Git itself, and sparse repository have old
|
|
objects that triggers this check, but it is recommended
|
|
to check new projects with this flag.
|
|
|
|
--verbose::
|
|
Be chatty.
|
|
|
|
--lost-found::
|
|
Write dangling objects into .git/lost-found/commit/ or
|
|
.git/lost-found/other/, depending on type. If the object is
|
|
a blob, the contents are written into the file, rather than
|
|
its object name.
|
|
|
|
--name-objects::
|
|
When displaying names of reachable objects, in addition to the
|
|
SHA-1 also display a name that describes *how* they are reachable,
|
|
compatible with linkgit:git-rev-parse[1], e.g.
|
|
`HEAD@{1234567890}~25^2:src/`.
|
|
|
|
--[no-]progress::
|
|
Progress status is reported on the standard error stream by
|
|
default when it is attached to a terminal, unless
|
|
--no-progress or --verbose is specified. --progress forces
|
|
progress status even if the standard error stream is not
|
|
directed to a terminal.
|
|
|
|
CONFIGURATION
|
|
-------------
|
|
|
|
include::includes/cmd-config-section-all.txt[]
|
|
|
|
include::config/fsck.txt[]
|
|
|
|
DISCUSSION
|
|
----------
|
|
|
|
git-fsck tests SHA-1 and general object sanity, and it does full tracking
|
|
of the resulting reachability and everything else. It prints out any
|
|
corruption it finds (missing or bad objects), and if you use the
|
|
`--unreachable` flag it will also print out objects that exist but that
|
|
aren't reachable from any of the specified head nodes (or the default
|
|
set, as mentioned above).
|
|
|
|
Any corrupt objects you will have to find in backups or other archives
|
|
(i.e., you can just remove them and do an 'rsync' with some other site in
|
|
the hopes that somebody else has the object you have corrupted).
|
|
|
|
If core.commitGraph is true, the commit-graph file will also be inspected
|
|
using 'git commit-graph verify'. See linkgit:git-commit-graph[1].
|
|
|
|
Extracted Diagnostics
|
|
---------------------
|
|
|
|
unreachable <type> <object>::
|
|
The <type> object <object>, isn't actually referred to directly
|
|
or indirectly in any of the trees or commits seen. This can
|
|
mean that there's another root node that you're not specifying
|
|
or that the tree is corrupt. If you haven't missed a root node
|
|
then you might as well delete unreachable nodes since they
|
|
can't be used.
|
|
|
|
missing <type> <object>::
|
|
The <type> object <object>, is referred to but isn't present in
|
|
the database.
|
|
|
|
dangling <type> <object>::
|
|
The <type> object <object>, is present in the database but never
|
|
'directly' used. A dangling commit could be a root node.
|
|
|
|
hash mismatch <object>::
|
|
The database has an object whose hash doesn't match the
|
|
object database value.
|
|
This indicates a serious data integrity problem.
|
|
|
|
Environment Variables
|
|
---------------------
|
|
|
|
GIT_OBJECT_DIRECTORY::
|
|
used to specify the object database root (usually $GIT_DIR/objects)
|
|
|
|
GIT_INDEX_FILE::
|
|
used to specify the index file of the index
|
|
|
|
GIT_ALTERNATE_OBJECT_DIRECTORIES::
|
|
used to specify additional object database roots (usually unset)
|
|
|
|
GIT
|
|
---
|
|
Part of the linkgit:git[1] suite
|