OSDN Git Service

Add Git official document to help
[tortoisegit/TortoiseGitJp.git] / doc / source / en / TortoiseGit / git_doc / git-fsck.html.xml
diff --git a/doc/source/en/TortoiseGit/git_doc/git-fsck.html.xml b/doc/source/en/TortoiseGit/git_doc/git-fsck.html.xml
new file mode 100644 (file)
index 0000000..983dd58
--- /dev/null
@@ -0,0 +1,304 @@
+<?xml version="1.0" encoding="UTF-8"?>\r
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">\r
+\r
+<article lang="en" id="git-fsck(1)">\r
+<articleinfo>\r
+    <title>git-fsck(1)</title>\r
+        <indexterm>\r
+                <primary>git-fsck(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-fsck - Verifies the connectivity and validity of the objects in the database</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git fsck</emphasis> [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]\r
+         [--full] [--strict] [--verbose] [--lost-found] [&lt;object&gt;*]</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Verifies the connectivity and validity of the objects in the database.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+&lt;object&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        An object to treat as the head of an unreachability trace.\r
+</simpara>\r
+<simpara>If no objects are given, <emphasis>git-fsck</emphasis> defaults to using the\r
+index file, all SHA1 references in .git/refs/*, and all reflogs (unless\r
+--no-reflogs is given) as heads.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--unreachable\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Print out objects that exist but that aren&#8217;t readable from any\r
+        of the reference nodes.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--root\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Report root nodes.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--tags\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Report tags.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--cache\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Consider any object recorded in the index also as a head node for\r
+        an unreachability trace.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-reflogs\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Do not consider commits that are referenced only by an\r
+        entry in a reflog to be reachable.  This option is meant\r
+        only to search for commits that used to be in a ref, but\r
+        now aren&#8217;t, but are still in that corresponding reflog.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--full\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Check not just objects in GIT_OBJECT_DIRECTORY\r
+        ($GIT_DIR/objects), but also the ones found in alternate\r
+        object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES\r
+        or $GIT_DIR/objects/info/alternates,\r
+        and in packed git archives found in $GIT_DIR/objects/pack\r
+        and corresponding pack subdirectories in alternate\r
+        object pools.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--strict\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Enable more strict checking, namely to catch a file mode\r
+        recorded with g+w bit set, which was created by older\r
+        versions of git.  Existing repositories, including the\r
+        Linux kernel, git itself, and sparse repository have old\r
+        objects that triggers this check, but it is recommended\r
+        to check new projects with this flag.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--verbose\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Be chatty.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--lost-found\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Write dangling objects into .git/lost-found/commit/ or\r
+        .git/lost-found/other/, depending on type.  If the object is\r
+        a blob, the contents are written into the file, rather than\r
+        its object name.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+<simpara>It tests SHA1 and general object sanity, and it does full tracking of\r
+the resulting reachability and everything else. It prints out any\r
+corruption it finds (missing or bad objects), and if you use the\r
+<emphasis>--unreachable</emphasis> flag it will also print out objects that exist but\r
+that aren&#8217;t readable from any of the specified head nodes.</simpara>\r
+<simpara>So for example</simpara>\r
+<literallayout class="monospaced">git fsck --unreachable HEAD \\r
+        $(git for-each-ref --format="%(objectname)" refs/heads)</literallayout>\r
+<simpara>will do quite a <emphasis>lot</emphasis> of verification on the tree. There are a few\r
+extra validity tests to be added (make sure that tree objects are\r
+sorted properly etc), but on the whole if <emphasis>git-fsck</emphasis> is happy, you\r
+do have a valid tree.</simpara>\r
+<simpara>Any corrupt objects you will have to find in backups or other archives\r
+(i.e., you can just remove them and do an <emphasis>rsync</emphasis> with some other site in\r
+the hopes that somebody else has the object you have corrupted).</simpara>\r
+<simpara>Of course, "valid tree" doesn&#8217;t mean that it wasn&#8217;t generated by some\r
+evil person, and the end result might be crap. git is a revision\r
+tracking system, not a quality assurance system ;)</simpara>\r
+</simplesect>\r
+<simplesect id="_extracted_diagnostics">\r
+<title>Extracted Diagnostics</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+expect dangling commits - potential heads - due to lack of head information\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        You haven&#8217;t specified any nodes as heads so it won&#8217;t be\r
+        possible to differentiate between un-parented commits and\r
+        root nodes.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+missing sha1 directory <emphasis>&lt;dir&gt;</emphasis>\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The directory holding the sha1 objects is missing.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+unreachable &lt;type&gt; &lt;object&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The &lt;type&gt; object &lt;object&gt;, isn&#8217;t actually referred to directly\r
+        or indirectly in any of the trees or commits seen. This can\r
+        mean that there&#8217;s another root node that you&#8217;re not specifying\r
+        or that the tree is corrupt. If you haven&#8217;t missed a root node\r
+        then you might as well delete unreachable nodes since they\r
+        can&#8217;t be used.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+missing &lt;type&gt; &lt;object&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The &lt;type&gt; object &lt;object&gt;, is referred to but isn&#8217;t present in\r
+        the database.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+dangling &lt;type&gt; &lt;object&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The &lt;type&gt; object &lt;object&gt;, is present in the database but never\r
+        <emphasis>directly</emphasis> used. A dangling commit could be a root node.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+warning: git-fsck: tree &lt;tree&gt; has full pathnames in it\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        And it shouldn&#8217;t&#8230;\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+sha1 mismatch &lt;object&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The database has an object who&#8217;s sha1 doesn&#8217;t match the\r
+        database value.\r
+        This indicates a serious data integrity problem.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_environment_variables">\r
+<title>Environment Variables</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+GIT_OBJECT_DIRECTORY\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        used to specify the object database root (usually $GIT_DIR/objects)\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+GIT_INDEX_FILE\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        used to specify the index file of the index\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+GIT_ALTERNATE_OBJECT_DIRECTORIES\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        used to specify additional object database roots (usually unset)\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Linus Torvalds &lt;<ulink url="mailto:torvalds@osdl.org">torvalds@osdl.org</ulink>&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_documentation">\r
+<title>Documentation</title>\r
+<simpara>Documentation by David Greaves, Junio C Hamano and the git-list &lt;<ulink url="mailto:git@vger.kernel.org">git@vger.kernel.org</ulink>&gt;.</simpara>\r
+</simplesect>\r
+<simplesect id="_git">\r
+<title>GIT</title>\r
+<simpara>Part of the <xref linkend="git(1)"/> suite</simpara>\r
+</simplesect>\r
+</article>\r