OSDN Git Service

Add Git official document to help
authorFrank Li <lznuaa@gmail.com>
Tue, 3 Mar 2009 13:27:05 +0000 (21:27 +0800)
committerFrank Li <lznuaa@gmail.com>
Wed, 4 Mar 2009 13:11:22 +0000 (21:11 +0800)
Signed-off-by: Frank Li <lznuaa@gmail.com>
155 files changed:
doc/source/en/TortoiseGit/git_doc/everyday.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-add.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-am.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-am.txt [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-annotate.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-apply.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-archimport.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-archive.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-bisect.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-blame.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-branch.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-bundle.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-cat-file.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-check-attr.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-check-ref-format.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-checkout-index.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-checkout.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-cherry-pick.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-cherry.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-citool.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-clean.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-clone.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-commit-tree.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-commit.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-config.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-count-objects.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-cvsexportcommit.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-cvsimport.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-cvsserver.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-daemon.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-describe.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-diff-files.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-diff-index.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-diff-tree.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-diff.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-doc.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-fast-export.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-fast-import.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-fetch-pack.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-fetch.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-filter-branch.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-fmt-merge-msg.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-for-each-ref.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-format-patch.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-fsck-objects.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-fsck.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-gc.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-get-tar-commit-id.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-grep.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-gui.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-hash-object.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-help.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-http-fetch.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-http-push.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-imap-send.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-index-pack.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-init-db.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-init.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-instaweb.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-log.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-lost-found.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-ls-files.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-ls-remote.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-ls-tree.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-mailinfo.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-mailsplit.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-merge-base.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-merge-file.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-merge-index.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-merge-one-file.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-merge-tree.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-merge.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-mergetool.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-mktag.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-mktree.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-mv.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-name-rev.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-notes.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-pack-objects.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-pack-redundant.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-pack-refs.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-parse-remote.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-patch-id.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-peek-remote.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-prune-packed.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-prune.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-pull.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-push.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-quiltimport.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-read-tree.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-rebase.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-receive-pack.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-reflog.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-relink.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-remote.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-repack.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-repo-config.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-request-pull.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-rerere.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-reset.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-rev-list.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-rev-parse.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-revert.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-rm.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-send-email.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-send-pack.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-sh-setup.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-shell.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-shortlog.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-show-branch.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-show-index.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-show-ref.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-show.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-stage.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-stash.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-status.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-stripspace.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-submodule.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-svn.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-symbolic-ref.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-tag.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-tar-tree.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-tools.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-unpack-file.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-unpack-objects.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-update-index.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-update-ref.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-update-server-info.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-upload-archive.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-upload-pack.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-var.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-vcs.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-verify-pack.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-verify-tag.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-web--browse.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-whatchanged.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git-write-tree.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/git.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitattributes.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitcli.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitcore-tutorial.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitcvs-migration.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitdiffcore.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitglossary.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/githooks.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitignore.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitk.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitmodules.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitrepository-layout.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gittutorial-2.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gittutorial.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/gitworkflows.html.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/howto-index.xml [new file with mode: 0644]
doc/source/en/TortoiseGit/git_doc/user-manual.xml [moved from doc/source/en/TortoiseGit/user-manual.xml with 95% similarity]
doc/source/en/TortoiseGit/tortoisegit.xml

diff --git a/doc/source/en/TortoiseGit/git_doc/everyday.xml b/doc/source/en/TortoiseGit/git_doc/everyday.xml
new file mode 100644 (file)
index 0000000..d36bc2e
--- /dev/null
@@ -0,0 +1,787 @@
+<?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="Everyday GIT With 20 Commands Or So">\r
+<articleinfo>\r
+    <title>Everyday GIT With 20 Commands Or So</title>\r
+        <indexterm>\r
+                <primary>Everyday GIT With 20 Commands Or So</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simpara><xref linkend="Basic Repository"/> commands are needed by people who have a\r
+repository --- that is everybody, because every working tree of\r
+git is a repository.</simpara>\r
+<simpara>In addition, <xref linkend="Individual Developer (Standalone)"/> commands are\r
+essential for anybody who makes a commit, even for somebody who\r
+works alone.</simpara>\r
+<simpara>If you work with other people, you will need commands listed in\r
+the <xref linkend="Individual Developer (Participant)"/> section as well.</simpara>\r
+<simpara>People who play the <xref linkend="Integrator"/> role need to learn some more\r
+commands in addition to the above.</simpara>\r
+<simpara><xref linkend="Repository Administration"/> commands are for system\r
+administrators who are responsible for the care and feeding\r
+of git repositories.</simpara>\r
+<simplesect id="_basic_repository_anchor_id_basic_repository_xreflabel_basic_repository">\r
+<title>Basic Repository<anchor id="Basic Repository" xreflabel="[Basic Repository]"/></title>\r
+<simpara>Everybody uses these commands to maintain git repositories.</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-init(1)"/> or <xref linkend="git-clone(1)"/> to create a\r
+    new repository.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-fsck(1)"/> to check the repository for errors.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-gc(1)"/> to do common housekeeping tasks such as\r
+    repack and prune.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simplesect id="_examples">\r
+<title>Examples</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+Check health and remove cruft.\r
+</term>\r
+<listitem>\r
+<literallayout>$ git fsck <co id="CO1-1"/>\r
+$ git count-objects <co id="CO1-2"/>\r
+$ git gc <co id="CO1-3"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO1-1">\r
+<simpara>\r
+running without <literal>--full</literal> is usually cheap and assures the\r
+repository health reasonably well.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO1-2">\r
+<simpara>\r
+check how many loose objects there are and how much\r
+disk space is wasted by not repacking.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO1-3">\r
+<simpara>\r
+repacks the local repository and performs other housekeeping tasks.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Repack a small project into single pack.\r
+</term>\r
+<listitem>\r
+<literallayout>$ git gc <co id="CO2-1"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO2-1">\r
+<simpara>\r
+pack all the objects reachable from the refs into one pack,\r
+then remove the other packs.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="_individual_developer_standalone_anchor_id_individual_developer_standalone_xreflabel_individual_developer_standalone">\r
+<title>Individual Developer (Standalone)<anchor id="Individual Developer (Standalone)" xreflabel="[Individual Developer (Standalone)]"/></title>\r
+<simpara>A standalone individual developer does not exchange patches with\r
+other people, and works alone in a single repository, using the\r
+following commands.</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-show-branch(1)"/> to see where you are.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-log(1)"/> to see what happened.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-checkout(1)"/> and <xref linkend="git-branch(1)"/> to switch\r
+    branches.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-add(1)"/> to manage the index file.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-diff(1)"/> and <xref linkend="git-status(1)"/> to see what\r
+    you are in the middle of doing.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-commit(1)"/> to advance the current branch.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-reset(1)"/> and <xref linkend="git-checkout(1)"/> (with\r
+    pathname parameters) to undo changes.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-merge(1)"/> to merge between local branches.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-rebase(1)"/> to maintain topic branches.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-tag(1)"/> to mark known point.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simplesect id="_examples_2">\r
+<title>Examples</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+Use a tarball as a starting point for a new repository.\r
+</term>\r
+<listitem>\r
+<literallayout>$ tar zxf frotz.tar.gz\r
+$ cd frotz\r
+$ git-init\r
+$ git add . <co id="CO3-1"/>\r
+$ git commit -m "import of frotz source tree."\r
+$ git tag v2.43 <co id="CO3-2"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO3-1">\r
+<simpara>\r
+add everything under the current directory.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO3-2">\r
+<simpara>\r
+make a lightweight, unannotated tag.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Create a topic branch and develop.\r
+</term>\r
+<listitem>\r
+<literallayout>$ git checkout -b alsa-audio <co id="CO4-1"/>\r
+$ edit/compile/test\r
+$ git checkout -- curses/ux_audio_oss.c <co id="CO4-2"/>\r
+$ git add curses/ux_audio_alsa.c <co id="CO4-3"/>\r
+$ edit/compile/test\r
+$ git diff HEAD <co id="CO4-4"/>\r
+$ git commit -a -s <co id="CO4-5"/>\r
+$ edit/compile/test\r
+$ git reset --soft HEAD^ <co id="CO4-6"/>\r
+$ edit/compile/test\r
+$ git diff ORIG_HEAD <co id="CO4-7"/>\r
+$ git commit -a -c ORIG_HEAD <co id="CO4-8"/>\r
+$ git checkout master <co id="CO4-9"/>\r
+$ git merge alsa-audio <co id="CO4-10"/>\r
+$ git log --since='3 days ago' <co id="CO4-11"/>\r
+$ git log v2.43.. curses/ <co id="CO4-12"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO4-1">\r
+<simpara>\r
+create a new topic branch.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-2">\r
+<simpara>\r
+revert your botched changes in <literal>curses/ux_audio_oss.c</literal>.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-3">\r
+<simpara>\r
+you need to tell git if you added a new file; removal and\r
+modification will be caught if you do <literal>git commit -a</literal> later.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-4">\r
+<simpara>\r
+to see what changes you are committing.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-5">\r
+<simpara>\r
+commit everything as you have tested, with your sign-off.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-6">\r
+<simpara>\r
+take the last commit back, keeping what is in the working tree.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-7">\r
+<simpara>\r
+look at the changes since the premature commit we took back.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-8">\r
+<simpara>\r
+redo the commit undone in the previous step, using the message\r
+you originally wrote.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-9">\r
+<simpara>\r
+switch to the master branch.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-10">\r
+<simpara>\r
+merge a topic branch into your master branch.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-11">\r
+<simpara>\r
+review commit logs; other forms to limit output can be\r
+combined and include <literal>--max-count=10</literal> (show 10 commits),\r
+<literal>--until=2005-12-10</literal>, etc.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO4-12">\r
+<simpara>\r
+view only the changes that touch what&#8217;s in <literal>curses/</literal>\r
+directory, since <literal>v2.43</literal> tag.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="_individual_developer_participant_anchor_id_individual_developer_participant_xreflabel_individual_developer_participant">\r
+<title>Individual Developer (Participant)<anchor id="Individual Developer (Participant)" xreflabel="[Individual Developer (Participant)]"/></title>\r
+<simpara>A developer working as a participant in a group project needs to\r
+learn how to communicate with others, and uses these commands in\r
+addition to the ones needed by a standalone developer.</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-clone(1)"/> from the upstream to prime your local\r
+    repository.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-pull(1)"/> and <xref linkend="git-fetch(1)"/> from "origin"\r
+    to keep up-to-date with the upstream.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-push(1)"/> to shared repository, if you adopt CVS\r
+    style shared repository workflow.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-format-patch(1)"/> to prepare e-mail submission, if\r
+    you adopt Linux kernel-style public forum workflow.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simplesect id="_examples_3">\r
+<title>Examples</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+Clone the upstream and work on it.  Feed changes to upstream.\r
+</term>\r
+<listitem>\r
+<literallayout>$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6\r
+$ cd my2.6\r
+$ edit/compile/test; git commit -a -s <co id="CO5-1"/>\r
+$ git format-patch origin <co id="CO5-2"/>\r
+$ git pull <co id="CO5-3"/>\r
+$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <co id="CO5-4"/>\r
+$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <co id="CO5-5"/>\r
+$ git reset --hard ORIG_HEAD <co id="CO5-6"/>\r
+$ git gc <co id="CO5-7"/>\r
+$ git fetch --tags <co id="CO5-8"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO5-1">\r
+<simpara>\r
+repeat as needed.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO5-2">\r
+<simpara>\r
+extract patches from your branch for e-mail submission.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO5-3">\r
+<simpara>\r
+<literal>git pull</literal> fetches from <literal>origin</literal> by default and merges into the\r
+current branch.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO5-4">\r
+<simpara>\r
+immediately after pulling, look at the changes done upstream\r
+since last time we checked, only in the\r
+area we are interested in.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO5-5">\r
+<simpara>\r
+fetch from a specific branch from a specific repository and merge.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO5-6">\r
+<simpara>\r
+revert the pull.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO5-7">\r
+<simpara>\r
+garbage collect leftover objects from reverted pull.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO5-8">\r
+<simpara>\r
+from time to time, obtain official tags from the <literal>origin</literal>\r
+and store them under <literal>.git/refs/tags/</literal>.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Push into another repository.\r
+</term>\r
+<listitem>\r
+<literallayout>satellite$ git clone mothership:frotz frotz <co id="CO6-1"/>\r
+satellite$ cd frotz\r
+satellite$ git config --get-regexp '^(remote|branch)\.' <co id="CO6-2"/>\r
+remote.origin.url mothership:frotz\r
+remote.origin.fetch refs/heads/*:refs/remotes/origin/*\r
+branch.master.remote origin\r
+branch.master.merge refs/heads/master\r
+satellite$ git config remote.origin.push \\r
+           master:refs/remotes/satellite/master <co id="CO6-3"/>\r
+satellite$ edit/compile/test/commit\r
+satellite$ git push origin <co id="CO6-4"/>\r
+\r
+mothership$ cd frotz\r
+mothership$ git checkout master\r
+mothership$ git merge satellite/master <co id="CO6-5"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO6-1">\r
+<simpara>\r
+mothership machine has a frotz repository under your home\r
+directory; clone from it to start a repository on the satellite\r
+machine.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO6-2">\r
+<simpara>\r
+clone sets these configuration variables by default.\r
+It arranges <literal>git pull</literal> to fetch and store the branches of mothership\r
+machine to local <literal>remotes/origin/*</literal> tracking branches.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO6-3">\r
+<simpara>\r
+arrange <literal>git push</literal> to push local <literal>master</literal> branch to\r
+<literal>remotes/satellite/master</literal> branch of the mothership machine.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO6-4">\r
+<simpara>\r
+push will stash our work away on <literal>remotes/satellite/master</literal>\r
+tracking branch on the mothership machine.  You could use this as\r
+a back-up method.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO6-5">\r
+<simpara>\r
+on mothership machine, merge the work done on the satellite\r
+machine into the master branch.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Branch off of a specific tag.\r
+</term>\r
+<listitem>\r
+<literallayout>$ git checkout -b private2.6.14 v2.6.14 <co id="CO7-1"/>\r
+$ edit/compile/test; git commit -a\r
+$ git checkout master\r
+$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |\r
+  git am -3 -k <co id="CO7-2"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO7-1">\r
+<simpara>\r
+create a private branch based on a well known (but somewhat behind)\r
+tag.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO7-2">\r
+<simpara>\r
+forward port all changes in <literal>private2.6.14</literal> branch to <literal>master</literal> branch\r
+without a formal "merging".\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="_integrator_anchor_id_integrator_xreflabel_integrator">\r
+<title>Integrator<anchor id="Integrator" xreflabel="[Integrator]"/></title>\r
+<simpara>A fairly central person acting as the integrator in a group\r
+project receives changes made by others, reviews and integrates\r
+them and publishes the result for others to use, using these\r
+commands in addition to the ones needed by participants.</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-am(1)"/> to apply patches e-mailed in from your\r
+    contributors.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-pull(1)"/> to merge from your trusted lieutenants.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-format-patch(1)"/> to prepare and send suggested\r
+    alternative to contributors.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-revert(1)"/> to undo botched commits.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-push(1)"/> to publish the bleeding edge.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simplesect id="_examples_4">\r
+<title>Examples</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+My typical GIT day.\r
+</term>\r
+<listitem>\r
+<literallayout>$ git status <co id="CO8-1"/>\r
+$ git show-branch <co id="CO8-2"/>\r
+$ mailx <co id="CO8-3"/>\r
+&amp; s 2 3 4 5 ./+to-apply\r
+&amp; s 7 8 ./+hold-linus\r
+&amp; q\r
+$ git checkout -b topic/one master\r
+$ git am -3 -i -s -u ./+to-apply <co id="CO8-4"/>\r
+$ compile/test\r
+$ git checkout -b hold/linus &amp;&amp; git am -3 -i -s -u ./+hold-linus <co id="CO8-5"/>\r
+$ git checkout topic/one &amp;&amp; git rebase master <co id="CO8-6"/>\r
+$ git checkout pu &amp;&amp; git reset --hard next <co id="CO8-7"/>\r
+$ git merge topic/one topic/two &amp;&amp; git merge hold/linus <co id="CO8-8"/>\r
+$ git checkout maint\r
+$ git cherry-pick master~4 <co id="CO8-9"/>\r
+$ compile/test\r
+$ git tag -s -m "GIT 0.99.9x" v0.99.9x <co id="CO8-10"/>\r
+$ git fetch ko &amp;&amp; git show-branch master maint 'tags/ko-*' <co id="CO8-11"/>\r
+$ git push ko <co id="CO8-12"/>\r
+$ git push ko v0.99.9x <co id="CO8-13"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO8-1">\r
+<simpara>\r
+see what I was in the middle of doing, if any.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-2">\r
+<simpara>\r
+see what topic branches I have and think about how ready\r
+they are.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-3">\r
+<simpara>\r
+read mails, save ones that are applicable, and save others\r
+that are not quite ready.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-4">\r
+<simpara>\r
+apply them, interactively, with my sign-offs.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-5">\r
+<simpara>\r
+create topic branch as needed and apply, again with my\r
+sign-offs.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-6">\r
+<simpara>\r
+rebase internal topic branch that has not been merged to the\r
+master, nor exposed as a part of a stable branch.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-7">\r
+<simpara>\r
+restart <literal>pu</literal> every time from the next.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-8">\r
+<simpara>\r
+and bundle topic branches still cooking.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-9">\r
+<simpara>\r
+backport a critical fix.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-10">\r
+<simpara>\r
+create a signed tag.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-11">\r
+<simpara>\r
+make sure I did not accidentally rewind master beyond what I\r
+already pushed out.  <literal>ko</literal> shorthand points at the repository I have\r
+at kernel.org, and looks like this:\r
+</simpara>\r
+<literallayout>$ cat .git/remotes/ko\r
+URL: kernel.org:/pub/scm/git/git.git\r
+Pull: master:refs/tags/ko-master\r
+Pull: next:refs/tags/ko-next\r
+Pull: maint:refs/tags/ko-maint\r
+Push: master\r
+Push: next\r
+Push: +pu\r
+Push: maint</literallayout>\r
+<simpara>In the output from <literal>git show-branch</literal>, <literal>master</literal> should have\r
+everything <literal>ko-master</literal> has, and <literal>next</literal> should have\r
+everything <literal>ko-next</literal> has.</simpara>\r
+</callout>\r
+<callout arearefs="CO8-12">\r
+<simpara>\r
+push out the bleeding edge.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO8-13">\r
+<simpara>\r
+push the tag out, too.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="_repository_administration_anchor_id_repository_administration_xreflabel_repository_administration">\r
+<title>Repository Administration<anchor id="Repository Administration" xreflabel="[Repository Administration]"/></title>\r
+<simpara>A repository administrator uses the following tools to set up\r
+and maintain access to the repository by developers.</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-daemon(1)"/> to allow anonymous download from\r
+    repository.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<xref linkend="git-shell(1)"/> can be used as a <emphasis>restricted login shell</emphasis>\r
+    for shared central repository users.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simpara><ulink url="howto/update-hook-example.txt">update hook howto</ulink> has a good\r
+example of managing a shared central repository.</simpara>\r
+<simplesect id="_examples_5">\r
+<title>Examples</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+We assume the following in /etc/services\r
+</term>\r
+<listitem>\r
+<literallayout>$ grep 9418 /etc/services\r
+git             9418/tcp                # Git Version Control System</literallayout>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Run git-daemon to serve /pub/scm from inetd.\r
+</term>\r
+<listitem>\r
+<literallayout>$ grep git /etc/inetd.conf\r
+git     stream  tcp     nowait  nobody \\r
+  /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm</literallayout>\r
+<simpara>The actual configuration line should be on one line.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Run git-daemon to serve /pub/scm from xinetd.\r
+</term>\r
+<listitem>\r
+<literallayout>$ cat /etc/xinetd.d/git-daemon\r
+# default: off\r
+# description: The git server offers access to git repositories\r
+service git\r
+{\r
+        disable = no\r
+        type            = UNLISTED\r
+        port            = 9418\r
+        socket_type     = stream\r
+        wait            = no\r
+        user            = nobody\r
+        server          = /usr/bin/git-daemon\r
+        server_args     = --inetd --export-all --base-path=/pub/scm\r
+        log_on_failure  += USERID\r
+}</literallayout>\r
+<simpara>Check your xinetd(8) documentation and setup, this is from a Fedora system.\r
+Others might be different.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Give push/pull only access to developers.\r
+</term>\r
+<listitem>\r
+<literallayout>$ grep git /etc/passwd <co id="CO9-1"/>\r
+alice:x:1000:1000::/home/alice:/usr/bin/git-shell\r
+bob:x:1001:1001::/home/bob:/usr/bin/git-shell\r
+cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell\r
+david:x:1003:1003::/home/david:/usr/bin/git-shell\r
+$ grep git /etc/shells <co id="CO9-2"/>\r
+/usr/bin/git-shell</literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO9-1">\r
+<simpara>\r
+log-in shell is set to /usr/bin/git-shell, which does not\r
+allow anything but <literal>git push</literal> and <literal>git pull</literal>.  The users should\r
+get an ssh access to the machine.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO9-2">\r
+<simpara>\r
+in many distributions /etc/shells needs to list what is used\r
+as the login shell.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+CVS-style shared repository.\r
+</term>\r
+<listitem>\r
+<literallayout>$ grep git /etc/group <co id="CO10-1"/>\r
+git:x:9418:alice,bob,cindy,david\r
+$ cd /home/devo.git\r
+$ ls -l <co id="CO10-2"/>\r
+  lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -&gt; refs/heads/master\r
+  drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches\r
+  -rw-rw-r--   1 david git    84 Dec  4 22:40 config\r
+  -rw-rw-r--   1 david git    58 Dec  4 22:40 description\r
+  drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks\r
+  -rw-rw-r--   1 david git 37504 Dec  4 22:40 index\r
+  drwxrwsr-x   2 david git  4096 Dec  4 22:40 info\r
+  drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects\r
+  drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs\r
+  drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes\r
+$ ls -l hooks/update <co id="CO10-3"/>\r
+  -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update\r
+$ cat info/allowed-users <co id="CO10-4"/>\r
+refs/heads/master       alice\|cindy\r
+refs/heads/doc-update   bob\r
+refs/tags/v[0-9]*       david</literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO10-1">\r
+<simpara>\r
+place the developers into the same git group.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO10-2">\r
+<simpara>\r
+and make the shared repository writable by the group.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO10-3">\r
+<simpara>\r
+use update-hook example by Carl from Documentation/howto/\r
+for branch policy control.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO10-4">\r
+<simpara>\r
+alice and cindy can push into master, only bob can push into doc-update.\r
+david is the release manager and is the only person who can\r
+create and push version tags.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+HTTP server to support dumb protocol transfer.\r
+</term>\r
+<listitem>\r
+<literallayout>dev$ git update-server-info <co id="CO11-1"/>\r
+dev$ ftp user@isp.example.com <co id="CO11-2"/>\r
+ftp&gt; cp -r .git /home/user/myproject.git</literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO11-1">\r
+<simpara>\r
+make sure your info/refs and objects/info/packs are up-to-date\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO11-2">\r
+<simpara>\r
+upload to public HTTP server hosted by your ISP.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+</simplesect>\r
+</article>\r
diff --git a/doc/source/en/TortoiseGit/git_doc/git-add.html.xml b/doc/source/en/TortoiseGit/git_doc/git-add.html.xml
new file mode 100644 (file)
index 0000000..071367d
--- /dev/null
@@ -0,0 +1,412 @@
+<?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-add(1)">\r
+<articleinfo>\r
+    <title>git-add(1)</title>\r
+        <indexterm>\r
+                <primary>git-add(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-add - Add file contents to the index</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git add</emphasis> [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]\r
+          [--all | [--update | -u]] [--intent-to-add | -N]\r
+          [--refresh] [--ignore-errors] [--] &lt;filepattern&gt;&#8230;</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>This command adds the current content of new or modified files to the\r
+index, thus staging that content for inclusion in the next commit.</simpara>\r
+<simpara>The "index" holds a snapshot of the content of the working tree, and it\r
+is this snapshot that is taken as the contents of the next commit.  Thus\r
+after making any changes to the working directory, and before running\r
+the commit command, you must use the <emphasis>add</emphasis> command to add any new or\r
+modified files to the index.</simpara>\r
+<simpara>This command can be performed multiple times before a commit.  It only\r
+adds the content of the specified file(s) at the time the add command is\r
+run; if you want subsequent changes included in the next commit, then\r
+you must run <emphasis>git add</emphasis> again to add the new content to the index.</simpara>\r
+<simpara>The <emphasis>git status</emphasis> command can be used to obtain a summary of which\r
+files have changes that are staged for the next commit.</simpara>\r
+<simpara>The <emphasis>git add</emphasis> command will not add ignored files by default.  If any\r
+ignored files were explicitly specified on the command line, <emphasis>git add</emphasis>\r
+will fail with a list of ignored files.  Ignored files reached by\r
+directory recursion or filename globbing performed by Git (quote your\r
+globs before the shell) will be silently ignored.  The <emphasis>add</emphasis> command can\r
+be used to add ignored files with the <literal>-f</literal> (force) option.</simpara>\r
+<simpara>Please see <xref linkend="git-commit(1)"/> for alternative ways to add content to a\r
+commit.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+&lt;filepattern&gt;&#8230;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Files to add content from.  Fileglobs (e.g. <literal>*.c</literal>) can\r
+        be given to add all matching files.  Also a\r
+        leading directory name (e.g. <literal>dir</literal> to add <literal>dir/file1</literal>\r
+        and <literal>dir/file2</literal>) can be given to add all files in the\r
+        directory, recursively.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-n\r
+</term>\r
+<term>\r
+--dry-run\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Don&#8217;t actually add the file(s), just show if they exist.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-v\r
+</term>\r
+<term>\r
+--verbose\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Be verbose.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-f\r
+</term>\r
+<term>\r
+--force\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Allow adding otherwise ignored files.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-i\r
+</term>\r
+<term>\r
+--interactive\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Add modified contents in the working tree interactively to\r
+        the index. Optional path arguments may be supplied to limit\r
+        operation to a subset of the working tree. See &#8220;Interactive\r
+        mode&#8221; for details.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-p\r
+</term>\r
+<term>\r
+--patch\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Similar to Interactive mode but the initial command loop is\r
+        bypassed and the <emphasis>patch</emphasis> subcommand is invoked using each of\r
+        the specified filepatterns before exiting.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-u\r
+</term>\r
+<term>\r
+--update\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Update only files that git already knows about, staging modified\r
+        content for commit and marking deleted files for removal. This\r
+        is similar\r
+        to what "git commit -a" does in preparation for making a commit,\r
+        except that the update is limited to paths specified on the\r
+        command line. If no paths are specified, all tracked files in the\r
+        current directory and its subdirectories are updated.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-A\r
+</term>\r
+<term>\r
+--all\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Update files that git already knows about (same as <emphasis>--update</emphasis>)\r
+        and add all untracked files that are not ignored by <emphasis>.gitignore</emphasis>\r
+        mechanism.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-N\r
+</term>\r
+<term>\r
+--intent-to-add\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Record only the fact that the path will be added later. An entry\r
+        for the path is placed in the index with no content. This is\r
+        useful for, among other things, showing the unstaged content of\r
+        such files with <emphasis>git diff</emphasis> and committing them with <emphasis>git commit\r
+        -a</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--refresh\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Don&#8217;t add the file(s), but only refresh their stat()\r
+        information in the index.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--ignore-errors\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If some files could not be added because of errors indexing\r
+        them, do not abort the operation, but continue adding the\r
+        others. The command shall still exit with non-zero status.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        This option can be used to separate command-line options from\r
+        the list of files, (useful when filenames might be mistaken\r
+        for command-line options).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_configuration">\r
+<title>Configuration</title>\r
+<simpara>The optional configuration variable <emphasis>core.excludesfile</emphasis> indicates a path to a\r
+file containing patterns of file names to exclude from git-add, similar to\r
+$GIT_DIR/info/exclude.  Patterns in the exclude file are used in addition to\r
+those in info/exclude.  See <xref linkend="gitrepository-layout(5)"/>.</simpara>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>EXAMPLES</title>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+Adds content from all <literal>\*.txt</literal> files under <literal>Documentation</literal> directory\r
+and its subdirectories:\r
+</simpara>\r
+<literallayout>$ git add Documentation/\\*.txt</literallayout>\r
+<simpara>Note that the asterisk <literal>\*</literal> is quoted from the shell in this\r
+example; this lets the command to include the files from\r
+subdirectories of <literal>Documentation/</literal> directory.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+Considers adding content from all git-*.sh scripts:\r
+</simpara>\r
+<literallayout>$ git add git-*.sh</literallayout>\r
+<simpara>Because this example lets shell expand the asterisk (i.e. you are\r
+listing the files explicitly), it does not consider\r
+<literal>subdir/git-foo.sh</literal>.</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+</simplesect>\r
+<simplesect id="_interactive_mode">\r
+<title>Interactive mode</title>\r
+<simpara>When the command enters the interactive mode, it shows the\r
+output of the <emphasis>status</emphasis> subcommand, and then goes into its\r
+interactive command loop.</simpara>\r
+<simpara>The command loop shows the list of subcommands available, and\r
+gives a prompt "What now&gt; ".  In general, when the prompt ends\r
+with a single <emphasis>&gt;</emphasis>, you can pick only one of the choices given\r
+and type return, like this:</simpara>\r
+<literallayout>    *** Commands ***\r
+      1: status       2: update       3: revert       4: add untracked\r
+      5: patch        6: diff         7: quit         8: help\r
+    What now&gt; 1</literallayout>\r
+<simpara>You also could say "s" or "sta" or "status" above as long as the\r
+choice is unique.</simpara>\r
+<simpara>The main command loop has 6 subcommands (plus help and quit).</simpara>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+status\r
+</term>\r
+<listitem>\r
+<simpara>\r
+   This shows the change between HEAD and index (i.e. what will be\r
+   committed if you say "git commit"), and between index and\r
+   working tree files (i.e. what you could stage further before\r
+   "git commit" using "git-add") for each path.  A sample output\r
+   looks like this:\r
+</simpara>\r
+<literallayout>              staged     unstaged path\r
+     1:       binary      nothing foo.png\r
+     2:     +403/-35        +1/-1 git-add--interactive.perl</literallayout>\r
+<simpara>It shows that foo.png has differences from HEAD (but that is\r
+binary so line count cannot be shown) and there is no\r
+difference between indexed copy and the working tree\r
+version (if the working tree version were also different,\r
+<emphasis>binary</emphasis> would have been shown in place of <emphasis>nothing</emphasis>).  The\r
+other file, git-add&#8212;interactive.perl, has 403 lines added\r
+and 35 lines deleted if you commit what is in the index, but\r
+working tree file has further modifications (one addition and\r
+one deletion).</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+update\r
+</term>\r
+<listitem>\r
+<simpara>\r
+   This shows the status information and gives prompt\r
+   "Update&gt;&gt;".  When the prompt ends with double <emphasis>&gt;&gt;</emphasis>, you can\r
+   make more than one selection, concatenated with whitespace or\r
+   comma.  Also you can say ranges.  E.g. "2-5 7,9" to choose\r
+   2,3,4,5,7,9 from the list.  If the second number in a range is\r
+   omitted, all remaining patches are taken.  E.g. "7-" to choose\r
+   7,8,9 from the list.  You can say <emphasis>*</emphasis> to choose everything.\r
+</simpara>\r
+<simpara>What you chose are then highlighted with <emphasis>*</emphasis>,\r
+like this:</simpara>\r
+<literallayout>           staged     unstaged path\r
+  1:       binary      nothing foo.png\r
+* 2:     +403/-35        +1/-1 git-add--interactive.perl</literallayout>\r
+<simpara>To remove selection, prefix the input with <literal>-</literal>\r
+like this:</simpara>\r
+<literallayout>Update&gt;&gt; -2</literallayout>\r
+<simpara>After making the selection, answer with an empty line to stage the\r
+contents of working tree files for selected paths in the index.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+revert\r
+</term>\r
+<listitem>\r
+<simpara>\r
+  This has a very similar UI to <emphasis>update</emphasis>, and the staged\r
+  information for selected paths are reverted to that of the\r
+  HEAD version.  Reverting new paths makes them untracked.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+add untracked\r
+</term>\r
+<listitem>\r
+<simpara>\r
+  This has a very similar UI to <emphasis>update</emphasis> and\r
+  <emphasis>revert</emphasis>, and lets you add untracked paths to the index.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+patch\r
+</term>\r
+<listitem>\r
+<simpara>\r
+  This lets you choose one path out of <emphasis>status</emphasis> like selection.\r
+  After choosing the path, it presents diff between the index\r
+  and the working tree file and asks you if you want to stage\r
+  the change of each hunk.  You can say:\r
+</simpara>\r
+<literallayout class="monospaced">y - stage this hunk\r
+n - do not stage this hunk\r
+a - stage this and all the remaining hunks in the file\r
+d - do not stage this hunk nor any of the remaining hunks in the file\r
+j - leave this hunk undecided, see next undecided hunk\r
+J - leave this hunk undecided, see next hunk\r
+k - leave this hunk undecided, see previous undecided hunk\r
+K - leave this hunk undecided, see previous hunk\r
+s - split the current hunk into smaller hunks\r
+e - manually edit the current hunk\r
+? - print help</literallayout>\r
+<simpara>After deciding the fate for all hunks, if there is any hunk\r
+that was chosen, the index is updated with the selected hunks.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+diff\r
+</term>\r
+<listitem>\r
+<simpara>\r
+  This lets you review what will be committed (i.e. between\r
+  HEAD and index).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_bugs">\r
+<title>Bugs</title>\r
+<simpara>The interactive mode does not work with files whose names contain\r
+characters that need C-quoting.  <literal>core.quotepath</literal> configuration can be\r
+used to work this limitation around to some degree, but backslash,\r
+double-quote and control characters will still have problems.</simpara>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="git-status(1)"/>\r
+<xref linkend="git-rm(1)"/>\r
+<xref linkend="git-reset(1)"/>\r
+<xref linkend="git-mv(1)"/>\r
+<xref linkend="git-commit(1)"/>\r
+<xref linkend="git-update-index(1)"/></simpara>\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 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-am.html.xml b/doc/source/en/TortoiseGit/git_doc/git-am.html.xml
new file mode 100644 (file)
index 0000000..9fdd61a
--- /dev/null
@@ -0,0 +1,322 @@
+<?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-am(1)">\r
+<articleinfo>\r
+    <title>git-am(1)</title>\r
+        <indexterm>\r
+                <primary>git-am(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-am - Apply a series of patches from a mailbox</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git am</emphasis> [--signoff] [--keep] [--utf8 | --no-utf8]\r
+         [--3way] [--interactive] [--committer-date-is-author-date]\r
+         [--ignore-date]\r
+         [--whitespace=&lt;option&gt;] [-C&lt;n&gt;] [-p&lt;n&gt;] [--directory=&lt;dir&gt;]\r
+         [--reject]\r
+         [&lt;mbox&gt; | &lt;Maildir&gt;&#8230;]\r
+<emphasis>git am</emphasis> (--skip | --resolved | --abort)</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Splits mail messages in a mailbox into commit log message,\r
+authorship information and patches, and applies them to the\r
+current branch.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+&lt;mbox&gt;|&lt;Maildir&gt;&#8230;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The list of mailbox files to read patches from. If you do not\r
+        supply this argument, reads from the standard input. If you supply\r
+        directories, they&#8217;ll be treated as Maildirs.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-s\r
+</term>\r
+<term>\r
+--signoff\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Add <literal>Signed-off-by:</literal> line to the commit message, using\r
+        the committer identity of yourself.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-k\r
+</term>\r
+<term>\r
+--keep\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Pass <literal>-k</literal> flag to <emphasis>git-mailinfo</emphasis> (see <xref linkend="git-mailinfo(1)"/>).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-u\r
+</term>\r
+<term>\r
+--utf8\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Pass <literal>-u</literal> flag to <emphasis>git-mailinfo</emphasis> (see <xref linkend="git-mailinfo(1)"/>).\r
+        The proposed commit log message taken from the e-mail\r
+        is re-coded into UTF-8 encoding (configuration variable\r
+        <literal>i18n.commitencoding</literal> can be used to specify project&#8217;s\r
+        preferred encoding if it is not UTF-8).\r
+</simpara>\r
+<simpara>This was optional in prior versions of git, but now it is the\r
+default.   You could use <literal>--no-utf8</literal> to override this.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-utf8\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Pass <literal>-n</literal> flag to <emphasis>git-mailinfo</emphasis> (see\r
+        <xref linkend="git-mailinfo(1)"/>).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-3\r
+</term>\r
+<term>\r
+--3way\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When the patch does not apply cleanly, fall back on\r
+        3-way merge, if the patch records the identity of blobs\r
+        it is supposed to apply to, and we have those blobs\r
+        available locally.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--whitespace=&lt;option&gt;\r
+</term>\r
+<term>\r
+-C&lt;n&gt;\r
+</term>\r
+<term>\r
+-p&lt;n&gt;\r
+</term>\r
+<term>\r
+--directory=&lt;dir&gt;\r
+</term>\r
+<term>\r
+--reject\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        These flags are passed to the <emphasis>git-apply</emphasis> (see <xref linkend="git-apply(1)"/>)\r
+        program that applies\r
+        the patch.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-i\r
+</term>\r
+<term>\r
+--interactive\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Run interactively.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--committer-date-is-author-date\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        By default the command records the date from the e-mail\r
+        message as the commit author date, and uses the time of\r
+        commit creation as the committer date. This allows the\r
+        user to lie about the committer date by using the same\r
+        timestamp as the author date.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--ignore-date\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        By default the command records the date from the e-mail\r
+        message as the commit author date, and uses the time of\r
+        commit creation as the committer date. This allows the\r
+        user to lie about author timestamp by using the same\r
+        timestamp as the committer date.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--skip\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Skip the current patch.  This is only meaningful when\r
+        restarting an aborted patch.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-r\r
+</term>\r
+<term>\r
+--resolved\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        After a patch failure (e.g. attempting to apply\r
+        conflicting patch), the user has applied it by hand and\r
+        the index file stores the result of the application.\r
+        Make a commit using the authorship and commit log\r
+        extracted from the e-mail message and the current index\r
+        file, and continue.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--resolvemsg=&lt;msg&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When a patch failure occurs, &lt;msg&gt; will be printed\r
+        to the screen before exiting.  This overrides the\r
+        standard message informing you to use <literal>--resolved</literal>\r
+        or <literal>--skip</literal> to handle the failure.  This is solely\r
+        for internal use between <emphasis>git-rebase</emphasis> and <emphasis>git-am</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--abort\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Restore the original branch and abort the patching operation.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_discussion">\r
+<title>DISCUSSION</title>\r
+<simpara>The commit author name is taken from the "From: " line of the\r
+message, and commit author time is taken from the "Date: " line\r
+of the message.  The "Subject: " line is used as the title of\r
+the commit, after stripping common prefix "[PATCH &lt;anything&gt;]".\r
+It is supposed to describe what the commit is about concisely as\r
+a one line text.</simpara>\r
+<simpara>The body of the message (iow, after a blank line that terminates\r
+RFC2822 headers) can begin with "Subject: " and "From: " lines\r
+that are different from those of the mail header, to override\r
+the values of these fields.</simpara>\r
+<simpara>The commit message is formed by the title taken from the\r
+"Subject: ", a blank line and the body of the message up to\r
+where the patch begins.  Excess whitespaces at the end of the\r
+lines are automatically stripped.</simpara>\r
+<simpara>The patch is expected to be inline, directly following the\r
+message.  Any line that is of form:</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+three-dashes and end-of-line, or\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+a line that begins with "diff -", or\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+a line that begins with "Index: "\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simpara>is taken as the beginning of a patch, and the commit log message\r
+is terminated before the first occurrence of such a line.</simpara>\r
+<simpara>When initially invoking it, you give it names of the mailboxes\r
+to crunch.  Upon seeing the first patch that does not apply, it\r
+aborts in the middle,.  You can recover from this in one of two ways:</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+skip the current patch by re-running the command with <emphasis>--skip</emphasis>\r
+  option.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+hand resolve the conflict in the working directory, and update\r
+  the index file to bring it in a state that the patch should\r
+  have produced.  Then run the command with <emphasis>--resolved</emphasis> option.\r
+</simpara>\r
+</listitem>\r
+</orderedlist>\r
+<simpara>The command refuses to process new mailboxes while <literal>.git/rebase-apply</literal>\r
+directory exists, so if you decide to start over from scratch,\r
+run <literal>rm -f -r .git/rebase-apply</literal> before running the command with mailbox\r
+names.</simpara>\r
+<simpara>Before any patches are applied, ORIG_HEAD is set to the tip of the\r
+current branch.  This is useful if you have problems with multiple\r
+commits, like running <emphasis>git am</emphasis> on the wrong branch or an error in the\r
+commits that is more easily fixed by changing the mailbox (e.g.\r
+errors in the "From:" lines).</simpara>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="git-apply(1)"/>.</simpara>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Junio C Hamano &lt;<ulink url="mailto:gitster@pobox.com">gitster@pobox.com</ulink>&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_documentation">\r
+<title>Documentation</title>\r
+<simpara>Documentation by Petr Baudis, 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-am.txt b/doc/source/en/TortoiseGit/git_doc/git-am.txt
new file mode 100644 (file)
index 0000000..ff307eb
--- /dev/null
@@ -0,0 +1,182 @@
+git-am(1)
+=========
+
+NAME
+----
+git-am - Apply a series of patches from a mailbox
+
+
+SYNOPSIS
+--------
+[verse]
+'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
+        [--3way] [--interactive] [--committer-date-is-author-date]
+        [--ignore-date]
+        [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
+        [--reject]
+        [<mbox> | <Maildir>...]
+'git am' (--skip | --resolved | --abort)
+
+DESCRIPTION
+-----------
+Splits mail messages in a mailbox into commit log message,
+authorship information and patches, and applies them to the
+current branch.
+
+OPTIONS
+-------
+<mbox>|<Maildir>...::
+       The list of mailbox files to read patches from. If you do not
+       supply this argument, reads from the standard input. If you supply
+       directories, they'll be treated as Maildirs.
+
+-s::
+--signoff::
+       Add `Signed-off-by:` line to the commit message, using
+       the committer identity of yourself.
+
+-k::
+--keep::
+       Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
+
+-u::
+--utf8::
+       Pass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
+       The proposed commit log message taken from the e-mail
+       is re-coded into UTF-8 encoding (configuration variable
+       `i18n.commitencoding` can be used to specify project's
+       preferred encoding if it is not UTF-8).
++
+This was optional in prior versions of git, but now it is the
+default.   You could use `--no-utf8` to override this.
+
+--no-utf8::
+       Pass `-n` flag to 'git-mailinfo' (see
+       linkgit:git-mailinfo[1]).
+
+-3::
+--3way::
+       When the patch does not apply cleanly, fall back on
+       3-way merge, if the patch records the identity of blobs
+       it is supposed to apply to, and we have those blobs
+       available locally.
+
+--whitespace=<option>::
+-C<n>::
+-p<n>::
+--directory=<dir>::
+--reject::
+       These flags are passed to the 'git-apply' (see linkgit:git-apply[1])
+       program that applies
+       the patch.
+
+-i::
+--interactive::
+       Run interactively.
+
+--committer-date-is-author-date::
+       By default the command records the date from the e-mail
+       message as the commit author date, and uses the time of
+       commit creation as the committer date. This allows the
+       user to lie about the committer date by using the same
+       timestamp as the author date.
+
+--ignore-date::
+       By default the command records the date from the e-mail
+       message as the commit author date, and uses the time of
+       commit creation as the committer date. This allows the
+       user to lie about author timestamp by using the same
+       timestamp as the committer date.
+
+--skip::
+       Skip the current patch.  This is only meaningful when
+       restarting an aborted patch.
+
+-r::
+--resolved::
+       After a patch failure (e.g. attempting to apply
+       conflicting patch), the user has applied it by hand and
+       the index file stores the result of the application.
+       Make a commit using the authorship and commit log
+       extracted from the e-mail message and the current index
+       file, and continue.
+
+--resolvemsg=<msg>::
+       When a patch failure occurs, <msg> will be printed
+       to the screen before exiting.  This overrides the
+       standard message informing you to use `--resolved`
+       or `--skip` to handle the failure.  This is solely
+       for internal use between 'git-rebase' and 'git-am'.
+
+--abort::
+       Restore the original branch and abort the patching operation.
+
+DISCUSSION
+----------
+
+The commit author name is taken from the "From: " line of the
+message, and commit author time is taken from the "Date: " line
+of the message.  The "Subject: " line is used as the title of
+the commit, after stripping common prefix "[PATCH <anything>]".
+It is supposed to describe what the commit is about concisely as
+a one line text.
+
+The body of the message (iow, after a blank line that terminates
+RFC2822 headers) can begin with "Subject: " and "From: " lines
+that are different from those of the mail header, to override
+the values of these fields.
+
+The commit message is formed by the title taken from the
+"Subject: ", a blank line and the body of the message up to
+where the patch begins.  Excess whitespaces at the end of the
+lines are automatically stripped.
+
+The patch is expected to be inline, directly following the
+message.  Any line that is of form:
+
+* three-dashes and end-of-line, or
+* a line that begins with "diff -", or
+* a line that begins with "Index: "
+
+is taken as the beginning of a patch, and the commit log message
+is terminated before the first occurrence of such a line.
+
+When initially invoking it, you give it names of the mailboxes
+to crunch.  Upon seeing the first patch that does not apply, it
+aborts in the middle,.  You can recover from this in one of two ways:
+
+. skip the current patch by re-running the command with '--skip'
+  option.
+
+. hand resolve the conflict in the working directory, and update
+  the index file to bring it in a state that the patch should
+  have produced.  Then run the command with '--resolved' option.
+
+The command refuses to process new mailboxes while `.git/rebase-apply`
+directory exists, so if you decide to start over from scratch,
+run `rm -f -r .git/rebase-apply` before running the command with mailbox
+names.
+
+Before any patches are applied, ORIG_HEAD is set to the tip of the
+current branch.  This is useful if you have problems with multiple
+commits, like running 'git am' on the wrong branch or an error in the
+commits that is more easily fixed by changing the mailbox (e.g.
+errors in the "From:" lines).
+
+
+SEE ALSO
+--------
+linkgit:git-apply[1].
+
+
+Author
+------
+Written by Junio C Hamano <gitster@pobox.com>
+
+Documentation
+--------------
+Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/doc/source/en/TortoiseGit/git_doc/git-annotate.html.xml b/doc/source/en/TortoiseGit/git_doc/git-annotate.html.xml
new file mode 100644 (file)
index 0000000..8d4e339
--- /dev/null
@@ -0,0 +1,247 @@
+<?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-annotate(1)">\r
+<articleinfo>\r
+    <title>git-annotate(1)</title>\r
+        <indexterm>\r
+                <primary>git-annotate(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-annotate - Annotate file lines with commit info</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara><emphasis>git annotate</emphasis> [options] file [revision]</simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Annotates each line in the given file with information from the commit\r
+which introduced the line. Optionally annotate from a given revision.</simpara>\r
+<simpara>The only difference between this command and <xref linkend="git-blame(1)"/> is that\r
+they use slightly different output formats, and this command exists only\r
+for backward compatibility to support existing scripts, and provide more\r
+familiar command name for people coming from other SCM systems.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-b\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show blank SHA-1 for boundary commits.  This can also\r
+        be controlled via the <literal>blame.blankboundary</literal> config option.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--root\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Do not treat root commits as boundaries.  This can also be\r
+        controlled via the <literal>blame.showroot</literal> config option.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--show-stats\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Include additional statistics at the end of blame output.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-L &lt;start&gt;,&lt;end&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Annotate only the given line range.  &lt;start&gt; and &lt;end&gt; can take\r
+        one of these forms:\r
+</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+number\r
+</simpara>\r
+<simpara>If &lt;start&gt; or &lt;end&gt; is a number, it specifies an\r
+absolute line number (lines count from 1).</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+/regex/\r
+</simpara>\r
+<simpara>This form will use the first line matching the given\r
+POSIX regex.  If &lt;end&gt; is a regex, it will search\r
+starting at the line given by &lt;start&gt;.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
++offset or -offset\r
+</simpara>\r
+<simpara>This is only valid for &lt;end&gt; and will specify a number\r
+of lines before or after the line given by &lt;start&gt;.</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-l\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show long rev (Default: off).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-t\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show raw timestamp (Default: off).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-S &lt;revs-file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Use revs from revs-file instead of calling <xref linkend="git-rev-list(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-p\r
+</term>\r
+<term>\r
+--porcelain\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show in a format designed for machine consumption.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--incremental\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show the result incrementally in a format designed for\r
+        machine consumption.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--encoding=&lt;encoding&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Specifies the encoding used to output author names\r
+        and commit summaries. Setting it to <literal>none</literal> makes blame\r
+        output unconverted data. For more information see the\r
+        discussion about encoding in the <xref linkend="git-log(1)"/>\r
+        manual page.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--contents &lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When &lt;rev&gt; is not specified, the command annotates the\r
+        changes starting backwards from the working tree copy.\r
+        This flag makes the command pretend as if the working\r
+        tree copy has the contents of the named file (specify\r
+        <literal>-</literal> to make the command read from the standard input).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-M|&lt;num&gt;|\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Detect moving lines in the file as well.  When a commit\r
+        moves a block of lines in a file (e.g. the original file\r
+        has A and then B, and the commit changes it to B and\r
+        then A), traditional <emphasis>blame</emphasis> algorithm typically blames\r
+        the lines that were moved up (i.e. B) to the parent and\r
+        assigns blame to the lines that were moved down (i.e. A)\r
+        to the child commit.  With this option, both groups of lines\r
+        are blamed on the parent.\r
+</simpara>\r
+<simpara>&lt;num&gt; is optional but it is the lower bound on the number of\r
+alphanumeric characters that git must detect as moving\r
+within a file for it to associate those lines with the parent\r
+commit.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-C|&lt;num&gt;|\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        In addition to <literal>-M</literal>, detect lines copied from other\r
+        files that were modified in the same commit.  This is\r
+        useful when you reorganize your program and move code\r
+        around across files.  When this option is given twice,\r
+        the command looks for copies from all other files in the\r
+        parent for the commit that creates the file in addition.\r
+</simpara>\r
+<simpara>&lt;num&gt; is optional but it is the lower bound on the number of\r
+alphanumeric characters that git must detect as moving\r
+between files for it to associate those lines with the parent\r
+commit.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-h\r
+</term>\r
+<term>\r
+--help\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show help message.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="git-blame(1)"/></simpara>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>AUTHOR</title>\r
+<simpara>Written by Ryan Anderson &lt;<ulink url="mailto:ryan@michonline.com">ryan@michonline.com</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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-apply.html.xml b/doc/source/en/TortoiseGit/git_doc/git-apply.html.xml
new file mode 100644 (file)
index 0000000..870e0a0
--- /dev/null
@@ -0,0 +1,445 @@
+<?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-apply(1)">\r
+<articleinfo>\r
+    <title>git-apply(1)</title>\r
+        <indexterm>\r
+                <primary>git-apply(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-apply - Apply a patch on a git index file and a working tree</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git apply</emphasis> [--stat] [--numstat] [--summary] [--check] [--index]\r
+          [--apply] [--no-add] [--build-fake-ancestor=&lt;file&gt;] [-R | --reverse]\r
+          [--allow-binary-replacement | --binary] [--reject] [-z]\r
+          [-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]\r
+          [--whitespace=&lt;nowarn|warn|fix|error|error-all&gt;]\r
+          [--exclude=PATH] [--include=PATH] [--directory=&lt;root&gt;]\r
+          [--verbose] [&lt;patch&gt;&#8230;]</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Reads supplied <emphasis>diff</emphasis> output and applies it on a git index file\r
+and a work tree.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+&lt;patch&gt;&#8230;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The files to read patch from.  <emphasis>-</emphasis> can be used to read\r
+        from the standard input.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--stat\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of applying the patch, output diffstat for the\r
+        input.  Turns off "apply".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--numstat\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Similar to --stat, but shows number of added and\r
+        deleted lines in decimal notation and pathname without\r
+        abbreviation, to make it more machine friendly.  For\r
+        binary files, outputs two <literal>-</literal> instead of saying\r
+        <literal>0 0</literal>.  Turns off "apply".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--summary\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of applying the patch, output a condensed\r
+        summary of information obtained from git diff extended\r
+        headers, such as creations, renames and mode changes.\r
+        Turns off "apply".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--check\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of applying the patch, see if the patch is\r
+        applicable to the current work tree and/or the index\r
+        file and detects errors.  Turns off "apply".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--index\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When --check is in effect, or when applying the patch\r
+        (which is the default when none of the options that\r
+        disables it is in effect), make sure the patch is\r
+        applicable to what the current index file records.  If\r
+        the file to be patched in the work tree is not\r
+        up-to-date, it is flagged as an error.  This flag also\r
+        causes the index file to be updated.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--cached\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Apply a patch without touching the working tree. Instead, take the\r
+        cached data, apply the patch, and store the result in the index,\r
+        without using the working tree. This implies <emphasis>--index</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--build-fake-ancestor=&lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Newer <emphasis>git-diff</emphasis> output has embedded <emphasis>index information</emphasis>\r
+        for each blob to help identify the original version that\r
+        the patch applies to.  When this flag is given, and if\r
+        the original versions of the blobs is available locally,\r
+        builds a temporary index containing those blobs.\r
+</simpara>\r
+<simpara>When a pure mode change is encountered (which has no index information),\r
+the information is read from the current index instead.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-R\r
+</term>\r
+<term>\r
+--reverse\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Apply the patch in reverse.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--reject\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        For atomicity, <emphasis>git-apply</emphasis> by default fails the whole patch and\r
+        does not touch the working tree when some of the hunks\r
+        do not apply.  This option makes it apply\r
+        the parts of the patch that are applicable, and leave the\r
+        rejected hunks in corresponding *.rej files.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-z\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When showing the index information, do not munge paths,\r
+        but use NUL terminated machine readable format.  Without\r
+        this flag, the pathnames output will have TAB, LF, and\r
+        backslash characters replaced with <literal>\t</literal>, <literal>\n</literal>, and <literal>\\</literal>,\r
+        respectively.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-p&lt;n&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Remove &lt;n&gt; leading slashes from traditional diff paths. The\r
+        default is 1.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-C&lt;n&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Ensure at least &lt;n&gt; lines of surrounding context match before\r
+        and after each change.  When fewer lines of surrounding\r
+        context exist they all must match.  By default no context is\r
+        ever ignored.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--unidiff-zero\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        By default, <emphasis>git-apply</emphasis> expects that the patch being\r
+        applied is a unified diff with at least one line of context.\r
+        This provides good safety measures, but breaks down when\r
+        applying a diff generated with --unified=0. To bypass these\r
+        checks use <emphasis>--unidiff-zero</emphasis>.\r
+</simpara>\r
+<simpara>Note, for the reasons stated above usage of context-free patches are\r
+discouraged.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--apply\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If you use any of the options marked "Turns off\r
+        <emphasis>apply</emphasis>" above, <emphasis>git-apply</emphasis> reads and outputs the\r
+        information you asked without actually applying the\r
+        patch.  Give this flag after those flags to also apply\r
+        the patch.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-add\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When applying a patch, ignore additions made by the\r
+        patch.  This can be used to extract the common part between\r
+        two files by first running <emphasis>diff</emphasis> on them and applying\r
+        the result with this option, which would apply the\r
+        deletion part but not addition part.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--allow-binary-replacement\r
+</term>\r
+<term>\r
+--binary\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Historically we did not allow binary patch applied\r
+        without an explicit permission from the user, and this\r
+        flag was the way to do so.  Currently we always allow binary\r
+        patch application, so this is a no-op.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--exclude=&lt;path-pattern&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Don&#8217;t apply changes to files matching the given path pattern. This can\r
+        be useful when importing patchsets, where you want to exclude certain\r
+        files or directories.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--include=&lt;path-pattern&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Apply changes to files matching the given path pattern. This can\r
+        be useful when importing patchsets, where you want to include certain\r
+        files or directories.\r
+</simpara>\r
+<simpara>When --exclude and --include patterns are used, they are examined in the\r
+order they appear on the command line, and the first match determines if a\r
+patch to each path is used.  A patch to a path that does not match any\r
+include/exclude pattern is used by default if there is no include pattern\r
+on the command line, and ignored if there is any include pattern.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--whitespace=&lt;action&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When applying a patch, detect a new or modified line that has\r
+        whitespace errors.  What are considered whitespace errors is\r
+        controlled by <literal>core.whitespace</literal> configuration.  By default,\r
+        trailing whitespaces (including lines that solely consist of\r
+        whitespaces) and a space character that is immediately followed\r
+        by a tab character inside the initial indent of the line are\r
+        considered whitespace errors.\r
+</simpara>\r
+<simpara>By default, the command outputs warning messages but applies the patch.\r
+When <literal>git-apply is used for statistics and not applying a\r
+patch, it defaults to `nowarn</literal>.</simpara>\r
+<simpara>You can use different <literal>&lt;action&gt;</literal> to control this\r
+behavior:</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+<literal>nowarn</literal> turns off the trailing whitespace warning.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<literal>warn</literal> outputs warnings for a few such errors, but applies the\r
+  patch as-is (default).\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<literal>fix</literal> outputs warnings for a few such errors, and applies the\r
+  patch after fixing them (<literal>strip</literal> is a synonym --- the tool\r
+  used to consider only trailing whitespaces as errors, and the\r
+  fix involved <emphasis>stripping</emphasis> them, but modern gits do more).\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<literal>error</literal> outputs warnings for a few such errors, and refuses\r
+  to apply the patch.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<literal>error-all</literal> is similar to <literal>error</literal> but shows all errors.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--inaccurate-eof\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Under certain circumstances, some versions of <emphasis>diff</emphasis> do not correctly\r
+        detect a missing new-line at the end of the file. As a result, patches\r
+        created by such <emphasis>diff</emphasis> programs do not record incomplete lines\r
+        correctly. This option adds support for applying such patches by\r
+        working around this bug.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-v\r
+</term>\r
+<term>\r
+--verbose\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Report progress to stderr. By default, only a message about the\r
+        current patch being applied will be printed. This option will cause\r
+        additional information to be reported.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--recount\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Do not trust the line counts in the hunk headers, but infer them\r
+        by inspecting the patch (e.g. after editing the patch without\r
+        adjusting the hunk headers appropriately).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--directory=&lt;root&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Prepend &lt;root&gt; to all filenames.  If a "-p" argument was passed, too,\r
+        it is applied before prepending the new root.\r
+</simpara>\r
+<simpara>For example, a patch that talks about updating <literal>a/git-gui.sh</literal> to <literal>b/git-gui.sh</literal>\r
+can be applied to the file in the working tree <literal>modules/git-gui/git-gui.sh</literal> by\r
+running <literal>git apply --directory=modules/git-gui</literal>.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_configuration">\r
+<title>Configuration</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+apply.whitespace\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When no <literal>--whitespace</literal> flag is given from the command\r
+        line, this configuration item is used as the default.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_submodules">\r
+<title>Submodules</title>\r
+<simpara>If the patch contains any changes to submodules then <emphasis>git-apply</emphasis>\r
+treats these changes as follows.</simpara>\r
+<simpara>If --index is specified (explicitly or implicitly), then the submodule\r
+commits must match the index exactly for the patch to apply.  If any\r
+of the submodules are checked-out, then these check-outs are completely\r
+ignored, i.e., they are not required to be up-to-date or clean and they\r
+are not updated.</simpara>\r
+<simpara>If --index is not specified, then the submodule commits in the patch\r
+are ignored and only the absence of presence of the corresponding\r
+subdirectory is checked and (if possible) updated.</simpara>\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 Junio C Hamano</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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-archimport.html.xml b/doc/source/en/TortoiseGit/git_doc/git-archimport.html.xml
new file mode 100644 (file)
index 0000000..e50503e
--- /dev/null
@@ -0,0 +1,184 @@
+<?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-archimport(1)">\r
+<articleinfo>\r
+    <title>git-archimport(1)</title>\r
+        <indexterm>\r
+                <primary>git-archimport(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-archimport - Import an Arch repository into git</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git archimport</emphasis> [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]\r
+               &lt;archive/branch&gt;[:&lt;git-branch&gt;] &#8230;</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Imports a project from one or more Arch repositories. It will follow branches\r
+and repositories within the namespaces defined by the &lt;archive/branch&gt;\r
+parameters supplied. If it cannot find the remote branch a merge comes from\r
+it will just import it as a regular commit. If it can find it, it will mark it\r
+as a merge whenever possible (see discussion below).</simpara>\r
+<simpara>The script expects you to provide the key roots where it can start the import\r
+from an <emphasis>initial import</emphasis> or <emphasis>tag</emphasis> type of Arch commit. It will follow and\r
+import new branches within the provided roots.</simpara>\r
+<simpara>It expects to be dealing with one project only. If it sees\r
+branches that have different roots, it will refuse to run. In that case,\r
+edit your &lt;archive/branch&gt; parameters to define clearly the scope of the\r
+import.</simpara>\r
+<simpara><emphasis>git-archimport</emphasis> uses <literal>tla</literal> extensively in the background to access the\r
+Arch repository.\r
+Make sure you have a recent version of <literal>tla</literal> available in the path. <literal>tla</literal> must\r
+know about the repositories you pass to <emphasis>git-archimport</emphasis>.</simpara>\r
+<simpara>For the initial import, <emphasis>git-archimport</emphasis> expects to find itself in an empty\r
+directory. To follow the development of a project that uses Arch, rerun\r
+<emphasis>git-archimport</emphasis> with the same parameters as the initial import to perform\r
+incremental imports.</simpara>\r
+<simpara>While <emphasis>git-archimport</emphasis> will try to create sensible branch names for the\r
+archives that it imports, it is also possible to specify git branch names\r
+manually.  To do so, write a git branch name after each &lt;archive/branch&gt;\r
+parameter, separated by a colon.  This way, you can shorten the Arch\r
+branch names and convert Arch jargon to git jargon, for example mapping a\r
+"PROJECT&#8212;devo&#8212;VERSION" branch to "master".</simpara>\r
+<simpara>Associating multiple Arch branches to one git branch is possible; the\r
+result will make the most sense only if no commits are made to the first\r
+branch, after the second branch is created.  Still, this is useful to\r
+convert Arch repositories that had been rotated periodically.</simpara>\r
+</simplesect>\r
+<simplesect id="_merges">\r
+<title>MERGES</title>\r
+<simpara>Patch merge data from Arch is used to mark merges in git as well. git\r
+does not care much about tracking patches, and only considers a merge when a\r
+branch incorporates all the commits since the point they forked. The end result\r
+is that git will have a good idea of how far branches have diverged. So the\r
+import process does lose some patch-trading metadata.</simpara>\r
+<simpara>Fortunately, when you try and merge branches imported from Arch,\r
+git will find a good merge base, and it has a good chance of identifying\r
+patches that have been traded out-of-sequence between the branches.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-h\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Display usage.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-v\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Verbose output.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-T\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Many tags. Will create a tag for every commit, reflecting the commit\r
+        name in the Arch repository.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-f\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Use the fast patchset import strategy.  This can be significantly\r
+        faster for large trees, but cannot handle directory renames or\r
+        permissions changes.  The default strategy is slow and safe.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-o\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Use this for compatibility with old-style branch names used by\r
+        earlier versions of <emphasis>git-archimport</emphasis>.  Old-style branch names\r
+        were category&#8212;branch, whereas new-style branch names are\r
+        archive,category&#8212;branch&#8212;version.  In both cases, names given\r
+        on the command-line will override the automatically-generated\r
+        ones.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-D &lt;depth&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Follow merge ancestry and attempt to import trees that have been\r
+        merged from.  Specify a depth greater than 1 if patch logs have been\r
+        pruned.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-a\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Attempt to auto-register archives at <ulink url="http://mirrors.sourcecontrol.net">http://mirrors.sourcecontrol.net</ulink>\r
+        This is particularly useful with the -D option.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-t &lt;tmpdir&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Override the default tempdir.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;archive/branch&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Archive/branch identifier in a format that <literal>tla log</literal> understands.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Martin Langhoff &lt;<ulink url="mailto:martin@catalyst.net.nz">martin@catalyst.net.nz</ulink>&gt;.</simpara>\r
+</simplesect>\r
+<simplesect id="_documentation">\r
+<title>Documentation</title>\r
+<simpara>Documentation by Junio C Hamano, Martin Langhoff 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-archive.html.xml b/doc/source/en/TortoiseGit/git_doc/git-archive.html.xml
new file mode 100644 (file)
index 0000000..7703506
--- /dev/null
@@ -0,0 +1,265 @@
+<?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-archive(1)">\r
+<articleinfo>\r
+    <title>git-archive(1)</title>\r
+        <indexterm>\r
+                <primary>git-archive(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-archive - Create an archive of files from a named tree</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git archive</emphasis> --format=&lt;fmt&gt; [--list] [--prefix=&lt;prefix&gt;/] [&lt;extra&gt;]\r
+              [--remote=&lt;repo&gt; [--exec=&lt;git-upload-archive&gt;]] &lt;tree-ish&gt;\r
+              [path&#8230;]</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Creates an archive of the specified format containing the tree\r
+structure for the named tree, and writes it out to the standard\r
+output.  If &lt;prefix&gt; is specified it is\r
+prepended to the filenames in the archive.</simpara>\r
+<simpara><emphasis>git-archive</emphasis> behaves differently when given a tree ID versus when\r
+given a commit ID or tag ID.  In the first case the current time is\r
+used as modification time of each file in the archive.  In the latter\r
+case the commit time as recorded in the referenced commit object is\r
+used instead.  Additionally the commit ID is stored in a global\r
+extended pax header if the tar format is used; it can be extracted\r
+using <emphasis>git-get-tar-commit-id</emphasis>. In ZIP files it is stored as a file\r
+comment.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+--format=&lt;fmt&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Format of the resulting archive: <emphasis>tar</emphasis> or <emphasis>zip</emphasis>.  The default\r
+        is <emphasis>tar</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-l\r
+</term>\r
+<term>\r
+--list\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show all available formats.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-v\r
+</term>\r
+<term>\r
+--verbose\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Report progress to stderr.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--prefix=&lt;prefix&gt;/\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Prepend &lt;prefix&gt;/ to each filename in the archive.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--submodules[=&lt;spec&gt;]\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Include the content of submodules in the archive. The specification\r
+        of which submodules to include can be either <emphasis>checkedout</emphasis> (default)\r
+        or <emphasis>all</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;extra&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        This can be any options that the archiver backend understand.\r
+        See next section.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--remote=&lt;repo&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of making a tar archive from local repository,\r
+        retrieve a tar archive from a remote repository.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--exec=&lt;git-upload-archive&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Used with --remote to specify the path to the\r
+        <emphasis>git-upload-archive</emphasis> on the remote side.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;tree-ish&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The tree or commit to produce an archive for.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+path\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If one or more paths are specified, include only these in the\r
+        archive, otherwise include all files and subdirectories.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_backend_extra_options">\r
+<title>BACKEND EXTRA OPTIONS</title>\r
+<simplesect id="_zip">\r
+<title>zip</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-0\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Store the files instead of deflating them.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-9\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Highest and slowest compression level.  You can specify any\r
+        number from 1 to 9 to adjust compression speed and ratio.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="_configuration">\r
+<title>CONFIGURATION</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+tar.umask\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        This variable can be used to restrict the permission bits of\r
+        tar archive entries.  The default is 0002, which turns off the\r
+        world write bit.  The special value "user" indicates that the\r
+        archiving user&#8217;s umask will be used instead.  See umask(2) for\r
+        details.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>EXAMPLES</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ &amp;&amp; tar xf -)\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Create a tar archive that contains the contents of the\r
+        latest commit on the current branch, and extracts it in\r
+        <literal>/var/tmp/junk</literal> directory.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip &gt;git-1.4.0.tar.gz\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Create a compressed tarball for v1.4.0 release.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+git archive --format=tar --prefix=git-1.4.0/ v1.4.0&#94;{tree} | gzip &gt;git-1.4.0.tar.gz\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Create a compressed tarball for v1.4.0 release, but without a\r
+        global extended pax header.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ &gt; git-1.4.0-docs.zip\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Put everything in the current head&#8217;s Documentation/ directory\r
+        into <emphasis>git-1.4.0-docs.zip</emphasis>, with the prefix <emphasis>git-docs/</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Franck Bui-Huu and Rene Scharfe.</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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-bisect.html.xml b/doc/source/en/TortoiseGit/git_doc/git-bisect.html.xml
new file mode 100644 (file)
index 0000000..cec079a
--- /dev/null
@@ -0,0 +1,227 @@
+<?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-bisect(1)">\r
+<articleinfo>\r
+    <title>git-bisect(1)</title>\r
+        <indexterm>\r
+                <primary>git-bisect(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-bisect - Find the change that introduced a bug by binary search</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara><emphasis>git bisect</emphasis> &lt;subcommand&gt; &lt;options&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>The command takes various subcommands, and different options depending\r
+on the subcommand:</simpara>\r
+<literallayout class="monospaced">git bisect help\r
+git bisect start [&lt;bad&gt; [&lt;good&gt;...]] [--] [&lt;paths&gt;...]\r
+git bisect bad [&lt;rev&gt;]\r
+git bisect good [&lt;rev&gt;...]\r
+git bisect skip [(&lt;rev&gt;|&lt;range&gt;)...]\r
+git bisect reset [&lt;branch&gt;]\r
+git bisect visualize\r
+git bisect replay &lt;logfile&gt;\r
+git bisect log\r
+git bisect run &lt;cmd&gt;...</literallayout>\r
+<simpara>This command uses <emphasis>git rev-list --bisect</emphasis> to help drive the\r
+binary search process to find which change introduced a bug, given an\r
+old "good" commit object name and a later "bad" commit object name.</simpara>\r
+<simplesect id="_getting_help">\r
+<title>Getting help</title>\r
+<simpara>Use "git bisect" to get a short usage description, and "git bisect\r
+help" or "git bisect -h" to get a long usage description.</simpara>\r
+</simplesect>\r
+<simplesect id="_basic_bisect_commands_start_bad_good">\r
+<title>Basic bisect commands: start, bad, good</title>\r
+<simpara>The way you use it is:</simpara>\r
+<literallayout>$ git bisect start\r
+$ git bisect bad                 # Current version is bad\r
+$ git bisect good v2.6.13-rc2    # v2.6.13-rc2 was the last version\r
+                                 # tested that was good</literallayout>\r
+<simpara>When you give at least one bad and one good versions, it will bisect\r
+the revision tree and say something like:</simpara>\r
+<literallayout>Bisecting: 675 revisions left to test after this</literallayout>\r
+<simpara>and check out the state in the middle. Now, compile that kernel, and\r
+boot it. Now, let&#8217;s say that this booted kernel works fine, then just\r
+do</simpara>\r
+<literallayout>$ git bisect good                       # this one is good</literallayout>\r
+<simpara>which will now say</simpara>\r
+<literallayout>Bisecting: 337 revisions left to test after this</literallayout>\r
+<simpara>and you continue along, compiling that one, testing it, and depending\r
+on whether it is good or bad, you say "git bisect good" or "git bisect\r
+bad", and ask for the next bisection.</simpara>\r
+<simpara>Until you have no more left, and you&#8217;ll have been left with the first\r
+bad kernel rev in "refs/bisect/bad".</simpara>\r
+</simplesect>\r
+<simplesect id="_bisect_reset">\r
+<title>Bisect reset</title>\r
+<simpara>Oh, and then after you want to reset to the original head, do a</simpara>\r
+<literallayout>$ git bisect reset</literallayout>\r
+<simpara>to get back to the original branch, instead of being on the bisection\r
+commit ("git bisect start" will do that for you too, actually: it will\r
+reset the bisection state).</simpara>\r
+</simplesect>\r
+<simplesect id="_bisect_visualize">\r
+<title>Bisect visualize</title>\r
+<simpara>During the bisection process, you can say</simpara>\r
+<literallayout>$ git bisect visualize</literallayout>\r
+<simpara>to see the currently remaining suspects in <emphasis>gitk</emphasis>.  <literal>visualize</literal> is a bit\r
+too long to type and <literal>view</literal> is provided as a synonym.</simpara>\r
+<simpara>If <emphasis>DISPLAY</emphasis> environment variable is not set, <emphasis>git log</emphasis> is used\r
+instead.  You can even give command line options such as <literal>-p</literal> and\r
+<literal>--stat</literal>.</simpara>\r
+<literallayout>$ git bisect view --stat</literallayout>\r
+</simplesect>\r
+<simplesect id="_bisect_log_and_bisect_replay">\r
+<title>Bisect log and bisect replay</title>\r
+<simpara>The good/bad input is logged, and</simpara>\r
+<literallayout>$ git bisect log</literallayout>\r
+<simpara>shows what you have done so far. You can truncate its output somewhere\r
+and save it in a file, and run</simpara>\r
+<literallayout>$ git bisect replay that-file</literallayout>\r
+<simpara>if you find later you made a mistake telling good/bad about a\r
+revision.</simpara>\r
+</simplesect>\r
+<simplesect id="_avoiding_to_test_a_commit">\r
+<title>Avoiding to test a commit</title>\r
+<simpara>If in a middle of bisect session, you know what the bisect suggested\r
+to try next is not a good one to test (e.g. the change the commit\r
+introduces is known not to work in your environment and you know it\r
+does not have anything to do with the bug you are chasing), you may\r
+want to find a near-by commit and try that instead.</simpara>\r
+<simpara>It goes something like this:</simpara>\r
+<literallayout>$ git bisect good/bad                   # previous round was good/bad.\r
+Bisecting: 337 revisions left to test after this\r
+$ git bisect visualize                  # oops, that is uninteresting.\r
+$ git reset --hard HEAD~3               # try 3 revs before what\r
+                                        # was suggested</literallayout>\r
+<simpara>Then compile and test the one you chose to try. After that, tell\r
+bisect what the result was as usual.</simpara>\r
+</simplesect>\r
+<simplesect id="_bisect_skip">\r
+<title>Bisect skip</title>\r
+<simpara>Instead of choosing by yourself a nearby commit, you may just want git\r
+to do it for you using:</simpara>\r
+<literallayout>$ git bisect skip                 # Current version cannot be tested</literallayout>\r
+<simpara>But computing the commit to test may be slower afterwards and git may\r
+eventually not be able to tell the first bad among a bad and one or\r
+more "skip"ped commits.</simpara>\r
+<simpara>You can even skip a range of commits, instead of just one commit,\r
+using the "<emphasis>&lt;commit1&gt;</emphasis>..<emphasis>&lt;commit2&gt;</emphasis>" notation. For example:</simpara>\r
+<literallayout>$ git bisect skip v2.5..v2.6</literallayout>\r
+<simpara>would mean that no commit between <literal>v2.5</literal> excluded and <literal>v2.6</literal> included\r
+can be tested.</simpara>\r
+<simpara>Note that if you want to also skip the first commit of a range you can\r
+use something like:</simpara>\r
+<literallayout>$ git bisect skip v2.5 v2.5..v2.6</literallayout>\r
+<simpara>and the commit pointed to by <literal>v2.5</literal> will be skipped too.</simpara>\r
+</simplesect>\r
+<simplesect id="_cutting_down_bisection_by_giving_more_parameters_to_bisect_start">\r
+<title>Cutting down bisection by giving more parameters to bisect start</title>\r
+<simpara>You can further cut down the number of trials if you know what part of\r
+the tree is involved in the problem you are tracking down, by giving\r
+paths parameters when you say <literal>bisect start</literal>, like this:</simpara>\r
+<literallayout>$ git bisect start -- arch/i386 include/asm-i386</literallayout>\r
+<simpara>If you know beforehand more than one good commits, you can narrow the\r
+bisect space down without doing the whole tree checkout every time you\r
+give good commits. You give the bad revision immediately after <literal>start</literal>\r
+and then you give all the good revisions you have:</simpara>\r
+<literallayout>$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --\r
+                   # v2.6.20-rc6 is bad\r
+                   # v2.6.20-rc4 and v2.6.20-rc1 are good</literallayout>\r
+</simplesect>\r
+<simplesect id="_bisect_run">\r
+<title>Bisect run</title>\r
+<simpara>If you have a script that can tell if the current source code is good\r
+or bad, you can automatically bisect using:</simpara>\r
+<literallayout>$ git bisect run my_script</literallayout>\r
+<simpara>Note that the "run" script (<literal>my_script</literal> in the above example) should\r
+exit with code 0 in case the current source code is good.  Exit with a\r
+code between 1 and 127 (inclusive), except 125, if the current\r
+source code is bad.</simpara>\r
+<simpara>Any other exit code will abort the automatic bisect process. (A\r
+program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,\r
+the value is chopped with "&amp; 0377".)</simpara>\r
+<simpara>The special exit code 125 should be used when the current source code\r
+cannot be tested. If the "run" script exits with this code, the current\r
+revision will be skipped, see <literal>git bisect skip</literal> above.</simpara>\r
+<simpara>You may often find that during bisect you want to have near-constant\r
+tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or\r
+"revision that does not have this commit needs this patch applied to\r
+work around other problem this bisection is not interested in")\r
+applied to the revision being tested.</simpara>\r
+<simpara>To cope with such a situation, after the inner <emphasis>git bisect</emphasis> finds the\r
+next revision to test, with the "run" script, you can apply that tweak\r
+before compiling, run the real test, and after the test decides if the\r
+revision (possibly with the needed tweaks) passed the test, rewind the\r
+tree to the pristine state.  Finally the "run" script can exit with\r
+the status of the real test to let the "git bisect run" command loop to\r
+determine the outcome.</simpara>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>EXAMPLES</title>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+Automatically bisect a broken build between v1.2 and HEAD:\r
+</simpara>\r
+<literallayout>$ git bisect start HEAD v1.2 --      # HEAD is bad, v1.2 is good\r
+$ git bisect run make                # "make" builds the app</literallayout>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+Automatically bisect a broken test suite:\r
+</simpara>\r
+<literallayout>$ cat ~/test.sh\r
+#!/bin/sh\r
+make || exit 125                   # this "skip"s broken builds\r
+make test                          # "make test" runs the test suite\r
+$ git bisect start v1.3 v1.1 --    # v1.3 is bad, v1.1 is good\r
+$ git bisect run ~/test.sh</literallayout>\r
+<simpara>Here we use a "test.sh" custom script. In this script, if "make"\r
+fails, we "skip" the current commit.</simpara>\r
+<simpara>It&#8217;s safer to use a custom script outside the repo to prevent\r
+interactions between the bisect, make and test processes and the\r
+script.</simpara>\r
+<simpara>And "make test" should "exit 0", if the test suite passes, and\r
+"exit 1" (for example) otherwise.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+Automatically bisect a broken test case:\r
+</simpara>\r
+<literallayout>$ cat ~/test.sh\r
+#!/bin/sh\r
+make || exit 125                     # this "skip"s broken builds\r
+~/check_test_case.sh                 # does the test case passes ?\r
+$ git bisect start HEAD HEAD~10 --   # culprit is among the last 10\r
+$ git bisect run ~/test.sh</literallayout>\r
+<simpara>Here "check_test_case.sh" should "exit 0", if the test case passes,\r
+and "exit 1" (for example) otherwise.</simpara>\r
+<simpara>It&#8217;s safer if both "test.sh" and "check_test_case.sh" scripts are\r
+outside the repo to prevent interactions between the bisect, make and\r
+test processes and the scripts.</simpara>\r
+</listitem>\r
+</itemizedlist>\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 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-blame.html.xml b/doc/source/en/TortoiseGit/git_doc/git-blame.html.xml
new file mode 100644 (file)
index 0000000..77f7e3e
--- /dev/null
@@ -0,0 +1,463 @@
+<?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-blame(1)">\r
+<articleinfo>\r
+    <title>git-blame(1)</title>\r
+        <indexterm>\r
+                <primary>git-blame(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-blame - Show what revision and author last modified each line of a file</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git blame</emphasis> [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]\r
+            [-S &lt;revs-file&gt;] [-M] [-C] [-C] [--since=&lt;date&gt;]\r
+            [&lt;rev&gt; | --contents &lt;file&gt;] [--] &lt;file&gt;</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Annotates each line in the given file with information from the revision which\r
+last modified the line. Optionally, start annotating from the given revision.</simpara>\r
+<simpara>Also it can limit the range of lines annotated.</simpara>\r
+<simpara>This report doesn&#8217;t tell you anything about lines which have been deleted or\r
+replaced; you need to use a tool such as <emphasis>git-diff</emphasis> or the "pickaxe"\r
+interface briefly mentioned in the following paragraph.</simpara>\r
+<simpara>Apart from supporting file annotation, git also supports searching the\r
+development history for when a code snippet occurred in a change. This makes it\r
+possible to track when a code snippet was added to a file, moved or copied\r
+between files, and eventually deleted or replaced. It works by searching for\r
+a text string in the diff. A small example:</simpara>\r
+<literallayout>$ git log --pretty=oneline -S'blame_usage'\r
+5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S &lt;ancestry-file&gt;\r
+ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output</literallayout>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-b\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show blank SHA-1 for boundary commits.  This can also\r
+        be controlled via the <literal>blame.blankboundary</literal> config option.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--root\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Do not treat root commits as boundaries.  This can also be\r
+        controlled via the <literal>blame.showroot</literal> config option.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--show-stats\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Include additional statistics at the end of blame output.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-L &lt;start&gt;,&lt;end&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Annotate only the given line range.  &lt;start&gt; and &lt;end&gt; can take\r
+        one of these forms:\r
+</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+number\r
+</simpara>\r
+<simpara>If &lt;start&gt; or &lt;end&gt; is a number, it specifies an\r
+absolute line number (lines count from 1).</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+/regex/\r
+</simpara>\r
+<simpara>This form will use the first line matching the given\r
+POSIX regex.  If &lt;end&gt; is a regex, it will search\r
+starting at the line given by &lt;start&gt;.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
++offset or -offset\r
+</simpara>\r
+<simpara>This is only valid for &lt;end&gt; and will specify a number\r
+of lines before or after the line given by &lt;start&gt;.</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-l\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show long rev (Default: off).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-t\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show raw timestamp (Default: off).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-S &lt;revs-file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Use revs from revs-file instead of calling <xref linkend="git-rev-list(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-p\r
+</term>\r
+<term>\r
+--porcelain\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show in a format designed for machine consumption.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--incremental\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show the result incrementally in a format designed for\r
+        machine consumption.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--encoding=&lt;encoding&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Specifies the encoding used to output author names\r
+        and commit summaries. Setting it to <literal>none</literal> makes blame\r
+        output unconverted data. For more information see the\r
+        discussion about encoding in the <xref linkend="git-log(1)"/>\r
+        manual page.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--contents &lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When &lt;rev&gt; is not specified, the command annotates the\r
+        changes starting backwards from the working tree copy.\r
+        This flag makes the command pretend as if the working\r
+        tree copy has the contents of the named file (specify\r
+        <literal>-</literal> to make the command read from the standard input).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-M|&lt;num&gt;|\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Detect moving lines in the file as well.  When a commit\r
+        moves a block of lines in a file (e.g. the original file\r
+        has A and then B, and the commit changes it to B and\r
+        then A), traditional <emphasis>blame</emphasis> algorithm typically blames\r
+        the lines that were moved up (i.e. B) to the parent and\r
+        assigns blame to the lines that were moved down (i.e. A)\r
+        to the child commit.  With this option, both groups of lines\r
+        are blamed on the parent.\r
+</simpara>\r
+<simpara>&lt;num&gt; is optional but it is the lower bound on the number of\r
+alphanumeric characters that git must detect as moving\r
+within a file for it to associate those lines with the parent\r
+commit.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-C|&lt;num&gt;|\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        In addition to <literal>-M</literal>, detect lines copied from other\r
+        files that were modified in the same commit.  This is\r
+        useful when you reorganize your program and move code\r
+        around across files.  When this option is given twice,\r
+        the command looks for copies from all other files in the\r
+        parent for the commit that creates the file in addition.\r
+</simpara>\r
+<simpara>&lt;num&gt; is optional but it is the lower bound on the number of\r
+alphanumeric characters that git must detect as moving\r
+between files for it to associate those lines with the parent\r
+commit.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-h\r
+</term>\r
+<term>\r
+--help\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show help message.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-c\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Use the same output mode as <xref linkend="git-annotate(1)"/> (Default: off).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--score-debug\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Include debugging information related to the movement of\r
+        lines between files (see <literal>-C</literal>) and lines moved within a\r
+        file (see <literal>-M</literal>).  The first number listed is the score.\r
+        This is the number of alphanumeric characters detected\r
+        to be moved between or within files.  This must be above\r
+        a certain threshold for <emphasis>git-blame</emphasis> to consider those lines\r
+        of code to have been moved.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-f\r
+</term>\r
+<term>\r
+--show-name\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show filename in the original commit.  By default\r
+        filename is shown if there is any line that came from a\r
+        file with different name, due to rename detection.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-n\r
+</term>\r
+<term>\r
+--show-number\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show line number in the original commit (Default: off).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-s\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Suppress author name and timestamp from the output.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-w\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Ignore whitespace when comparing parent&#8217;s version and\r
+        child&#8217;s to find where the lines came from.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_the_porcelain_format">\r
+<title>THE PORCELAIN FORMAT</title>\r
+<simpara>In this format, each line is output after a header; the\r
+header at the minimum has the first line which has:</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+40-byte SHA-1 of the commit the line is attributed to;\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+the line number of the line in the original file;\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+the line number of the line in the final file;\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+on a line that starts a group of line from a different\r
+  commit than the previous one, the number of lines in this\r
+  group.  On subsequent lines this field is absent.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simpara>This header line is followed by the following information\r
+at least once for each commit:</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+author name ("author"), email ("author-mail"), time\r
+  ("author-time"), and timezone ("author-tz"); similarly\r
+  for committer.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+filename in the commit the line is attributed to.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+the first line of the commit log message ("summary").\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simpara>The contents of the actual line is output after the above\r
+header, prefixed by a TAB. This is to allow adding more\r
+header elements later.</simpara>\r
+</simplesect>\r
+<simplesect id="_specifying_ranges">\r
+<title>SPECIFYING RANGES</title>\r
+<simpara>Unlike <emphasis>git-blame</emphasis> and <emphasis>git-annotate</emphasis> in older git, the extent\r
+of annotation can be limited to both line ranges and revision\r
+ranges.  When you are interested in finding the origin for\r
+ll. 40-60 for file <literal>foo</literal>, you can use <literal>-L</literal> option like these\r
+(they mean the same thing&#8201;&#8212;&#8201;both ask for 21 lines starting at\r
+line 40):</simpara>\r
+<literallayout class="monospaced">git blame -L 40,60 foo\r
+git blame -L 40,+21 foo</literallayout>\r
+<simpara>Also you can use regular expression to specify the line range.</simpara>\r
+<literallayout class="monospaced">git blame -L '/^sub hello {/,/^}$/' foo</literallayout>\r
+<simpara>would limit the annotation to the body of <literal>hello</literal> subroutine.</simpara>\r
+<simpara>When you are not interested in changes older than the version\r
+v2.6.18, or changes older than 3 weeks, you can use revision\r
+range specifiers  similar to <emphasis>git-rev-list</emphasis>:</simpara>\r
+<literallayout class="monospaced">git blame v2.6.18.. -- foo\r
+git blame --since=3.weeks -- foo</literallayout>\r
+<simpara>When revision range specifiers are used to limit the annotation,\r
+lines that have not changed since the range boundary (either the\r
+commit v2.6.18 or the most recent commit that is more than 3\r
+weeks old in the above example) are blamed for that range\r
+boundary commit.</simpara>\r
+<simpara>A particularly useful way is to see if an added file have lines\r
+created by copy-and-paste from existing files.  Sometimes this\r
+indicates that the developer was being sloppy and did not\r
+refactor the code properly.  You can first find the commit that\r
+introduced the file with:</simpara>\r
+<literallayout class="monospaced">git log --diff-filter=A --pretty=short -- foo</literallayout>\r
+<simpara>and then annotate the change between the commit and its\r
+parents, using <literal>commit&#94;!</literal> notation:</simpara>\r
+<literallayout class="monospaced">git blame -C -C -f $commit^! -- foo</literallayout>\r
+</simplesect>\r
+<simplesect id="_incremental_output">\r
+<title>INCREMENTAL OUTPUT</title>\r
+<simpara>When called with <literal>--incremental</literal> option, the command outputs the\r
+result as it is built.  The output generally will talk about\r
+lines touched by more recent commits first (i.e. the lines will\r
+be annotated out of order) and is meant to be used by\r
+interactive viewers.</simpara>\r
+<simpara>The output format is similar to the Porcelain format, but it\r
+does not contain the actual lines from the file that is being\r
+annotated.</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+Each blame entry always starts with a line of:\r
+</simpara>\r
+<literallayout class="monospaced">&lt;40-byte hex sha1&gt; &lt;sourceline&gt; &lt;resultline&gt; &lt;num_lines&gt;</literallayout>\r
+<simpara>Line numbers count from 1.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+The first time that commit shows up in the stream, it has various\r
+  other information about it printed out with a one-word tag at the\r
+  beginning of each line about that "extended commit info" (author,\r
+  email, committer, dates, summary etc).\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+Unlike Porcelain format, the filename information is always\r
+  given and terminates the entry:\r
+</simpara>\r
+<literallayout class="monospaced">"filename" &lt;whitespace-quoted-filename-goes-here&gt;</literallayout>\r
+<simpara>and thus it&#8217;s really quite easy to parse for some line- and word-oriented\r
+parser (which should be quite natural for most scripting languages).</simpara>\r
+<note><simpara>For people who do parsing: to make it more robust, just ignore any\r
+lines in between the first and last one ("&lt;sha1&gt;" and "filename" lines)\r
+where you don&#8217;t recognize the tag-words (or care about that particular\r
+one) at the beginning of the "extended information" lines. That way, if\r
+there is ever added information (like the commit encoding or extended\r
+commit commentary), a blame viewer won&#8217;t ever care.</simpara></note>\r
+</listitem>\r
+</orderedlist>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="git-annotate(1)"/></simpara>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>AUTHOR</title>\r
+<simpara>Written by Junio C Hamano &lt;<ulink url="mailto:gitster@pobox.com">gitster@pobox.com</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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-branch.html.xml b/doc/source/en/TortoiseGit/git_doc/git-branch.html.xml
new file mode 100644 (file)
index 0000000..f0e83ab
--- /dev/null
@@ -0,0 +1,403 @@
+<?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-branch(1)">\r
+<articleinfo>\r
+    <title>git-branch(1)</title>\r
+        <indexterm>\r
+                <primary>git-branch(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-branch - List, create, or delete branches</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git branch</emphasis> [--color | --no-color] [-r | -a]\r
+        [-v [--abbrev=&lt;length&gt; | --no-abbrev]]\r
+        [(--merged | --no-merged | --contains) [&lt;commit&gt;]]\r
+<emphasis>git branch</emphasis> [--track | --no-track] [-l] [-f] &lt;branchname&gt; [&lt;start-point&gt;]\r
+<emphasis>git branch</emphasis> (-m | -M) [&lt;oldbranch&gt;] &lt;newbranch&gt;\r
+<emphasis>git branch</emphasis> (-d | -D) [-r] &lt;branchname&gt;&#8230;</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>With no arguments, existing branches are listed, the current branch will\r
+be highlighted with an asterisk.  Option <literal>-r</literal> causes the remote-tracking\r
+branches to be listed, and option <literal>-a</literal> shows both.</simpara>\r
+<simpara>With <literal>--contains</literal>, shows only the branches that contains the named commit\r
+(in other words, the branches whose tip commits are descendant of the\r
+named commit).  With <literal>--merged</literal>, only branches merged into the named\r
+commit (i.e. the branches whose tip commits are reachable from the named\r
+commit) will be listed.  With <literal>--no-merged</literal> only branches not merged into\r
+the named commit will be listed.  Missing &lt;commit&gt; argument defaults to\r
+<emphasis>HEAD</emphasis> (i.e. the tip of the current branch).</simpara>\r
+<simpara>In its second form, a new branch named &lt;branchname&gt; will be created.\r
+It will start out with a head equal to the one given as &lt;start-point&gt;.\r
+If no &lt;start-point&gt; is given, the branch will be created with a head\r
+equal to that of the currently checked out branch.</simpara>\r
+<simpara>Note that this will create the new branch, but it will not switch the\r
+working tree to it; use "git checkout &lt;newbranch&gt;" to switch to the\r
+new branch.</simpara>\r
+<simpara>When a local branch is started off a remote branch, git sets up the\r
+branch so that <emphasis>git-pull</emphasis> will appropriately merge from\r
+the remote branch. This behavior may be changed via the global\r
+<literal>branch.autosetupmerge</literal> configuration flag. That setting can be\r
+overridden by using the <literal>--track</literal> and <literal>--no-track</literal> options.</simpara>\r
+<simpara>With a <emphasis>-m</emphasis> or <emphasis>-M</emphasis> option, &lt;oldbranch&gt; will be renamed to &lt;newbranch&gt;.\r
+If &lt;oldbranch&gt; had a corresponding reflog, it is renamed to match\r
+&lt;newbranch&gt;, and a reflog entry is created to remember the branch\r
+renaming. If &lt;newbranch&gt; exists, -M must be used to force the rename\r
+to happen.</simpara>\r
+<simpara>With a <literal>-d</literal> or <literal>-D</literal> option, <literal>&lt;branchname&gt;</literal> will be deleted.  You may\r
+specify more than one branch for deletion.  If the branch currently\r
+has a reflog then the reflog will also be deleted.</simpara>\r
+<simpara>Use -r together with -d to delete remote-tracking branches. Note, that it\r
+only makes sense to delete remote-tracking branches if they no longer exist\r
+in remote repository or if <emphasis>git-fetch</emphasis> was configured not to fetch\r
+them again. See also <emphasis>prune</emphasis> subcommand of <xref linkend="git-remote(1)"/> for way to\r
+clean up all obsolete remote-tracking branches.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-d\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Delete a branch. The branch must be fully merged in HEAD.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-D\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Delete a branch irrespective of its merged status.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-l\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Create the branch&#8217;s reflog.  This activates recording of\r
+        all changes made to the branch ref, enabling use of date\r
+        based sha1 expressions such as "&lt;branchname&gt;@{yesterday}".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-f\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Force the creation of a new branch even if it means deleting\r
+        a branch that already exists with the same name.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-m\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Move/rename a branch and the corresponding reflog.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-M\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Move/rename a branch even if the new branchname already exists.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--color\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Color branches to highlight current, local, and remote branches.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-color\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Turn off branch colors, even when the configuration file gives the\r
+        default to color output.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-r\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        List or delete (if used with -d) the remote-tracking branches.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-a\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        List both remote-tracking branches and local branches.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-v\r
+</term>\r
+<term>\r
+--verbose\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show sha1 and commit subject line for each head.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--abbrev=&lt;length&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Alter minimum display length for sha1 in output listing,\r
+        default value is 7.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-abbrev\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Display the full sha1s in output listing rather than abbreviating them.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--track\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When creating a new branch, set up configuration so that <emphasis>git-pull</emphasis>\r
+        will automatically retrieve data from the start point, which must be\r
+        a branch. Use this if you always pull from the same upstream branch\r
+        into the new branch, and if you don&#8217;t want to use "git pull\r
+        &lt;repository&gt; &lt;refspec&gt;" explicitly. This behavior is the default\r
+        when the start point is a remote branch. Set the\r
+        branch.autosetupmerge configuration variable to <literal>false</literal> if you want\r
+        <emphasis>git-checkout</emphasis> and <emphasis>git-branch</emphasis> to always behave as if <emphasis>--no-track</emphasis> were\r
+        given. Set it to <literal>always</literal> if you want this behavior when the\r
+        start-point is either a local or remote branch.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-track\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Ignore the branch.autosetupmerge configuration variable.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--contains &lt;commit&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Only list branches which contain the specified commit.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--merged\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Only list branches which are fully contained by HEAD.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-merged\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Do not list branches which are fully contained by HEAD.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;branchname&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The name of the branch to create or delete.\r
+        The new branch name must pass all checks defined by\r
+        <xref linkend="git-check-ref-format(1)"/>.  Some of these checks\r
+        may restrict the characters allowed in a branch name.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;start-point&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The new branch will be created with a HEAD equal to this.  It may\r
+        be given as a branch name, a commit-id, or a tag.  If this option\r
+        is omitted, the current branch is assumed.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;oldbranch&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The name of an existing branch to rename.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;newbranch&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The new name for an existing branch. The same restrictions as for\r
+        &lt;branchname&gt; applies.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>Examples</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+Start development off of a known tag\r
+</term>\r
+<listitem>\r
+<literallayout>$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6\r
+$ cd my2.6\r
+$ git branch my2.6.14 v2.6.14   <co id="CO1-1"/>\r
+$ git checkout my2.6.14</literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO1-1">\r
+<simpara>\r
+This step and the next one could be combined into a single step with\r
+"checkout -b my2.6.14 v2.6.14".\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Delete unneeded branch\r
+</term>\r
+<listitem>\r
+<literallayout>$ git clone git://git.kernel.org/.../git.git my.git\r
+$ cd my.git\r
+$ git branch -d -r origin/todo origin/html origin/man   <co id="CO2-1"/>\r
+$ git branch -D test                                    <co id="CO2-2"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO2-1">\r
+<simpara>\r
+Delete remote-tracking branches "todo", "html", "man". Next <emphasis>fetch</emphasis> or\r
+<emphasis>pull</emphasis> will create them again unless you configure them not to. See\r
+<xref linkend="git-fetch(1)"/>.\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO2-2">\r
+<simpara>\r
+Delete "test" branch even if the "master" branch (or whichever branch is\r
+currently checked out) does not have all commits from test branch.\r
+</simpara>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_notes">\r
+<title>Notes</title>\r
+<simpara>If you are creating a branch that you want to immediately checkout, it&#8217;s\r
+easier to use the git checkout command with its <literal>-b</literal> option to create\r
+a branch and check it out with a single command.</simpara>\r
+<simpara>The options <literal>--contains</literal>, <literal>--merged</literal> and <literal>--no-merged</literal> serves three related\r
+but different purposes:</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+<literal>--contains &lt;commit&gt;</literal> is used to find all branches which will need\r
+  special attention if &lt;commit&gt; were to be rebased or amended, since those\r
+  branches contain the specified &lt;commit&gt;.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<literal>--merged</literal> is used to find all branches which can be safely deleted,\r
+  since those branches are fully contained by HEAD.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<literal>--no-merged</literal> is used to find branches which are candidates for merging\r
+  into HEAD, since those branches are not fully contained by HEAD.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\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; and Junio C Hamano &lt;<ulink url="mailto:gitster@pobox.com">gitster@pobox.com</ulink>&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_documentation">\r
+<title>Documentation</title>\r
+<simpara>Documentation by 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-bundle.html.xml b/doc/source/en/TortoiseGit/git_doc/git-bundle.html.xml
new file mode 100644 (file)
index 0000000..3dc3cd7
--- /dev/null
@@ -0,0 +1,210 @@
+<?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-bundle(1)">\r
+<articleinfo>\r
+    <title>git-bundle(1)</title>\r
+        <indexterm>\r
+                <primary>git-bundle(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-bundle - Move objects and refs by archive</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git bundle</emphasis> create &lt;file&gt; &lt;git-rev-list args&gt;\r
+<emphasis>git bundle</emphasis> verify &lt;file&gt;\r
+<emphasis>git bundle</emphasis> list-heads &lt;file&gt; [refname&#8230;]\r
+<emphasis>git bundle</emphasis> unbundle &lt;file&gt; [refname&#8230;]</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Some workflows require that one or more branches of development on one\r
+machine be replicated on another machine, but the two machines cannot\r
+be directly connected so the interactive git protocols (git, ssh,\r
+rsync, http) cannot be used.  This command provides support for\r
+<emphasis>git-fetch</emphasis> and <emphasis>git-pull</emphasis> to operate by packaging objects and references\r
+in an archive at the originating machine, then importing those into\r
+another repository using <emphasis>git-fetch</emphasis> and <emphasis>git-pull</emphasis>\r
+after moving the archive by some means (i.e., by sneakernet).  As no\r
+direct connection between repositories exists, the user must specify a\r
+basis for the bundle that is held by the destination repository: the\r
+bundle assumes that all objects in the basis are already in the\r
+destination repository.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+create &lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+       Used to create a bundle named <emphasis>file</emphasis>.  This requires the\r
+       <emphasis>git-rev-list</emphasis> arguments to define the bundle contents.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+verify &lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+       Used to check that a bundle file is valid and will apply\r
+       cleanly to the current repository.  This includes checks on the\r
+       bundle format itself as well as checking that the prerequisite\r
+       commits exist and are fully linked in the current repository.\r
+       <emphasis>git-bundle</emphasis> prints a list of missing commits, if any, and exits\r
+       with non-zero status.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+list-heads &lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+       Lists the references defined in the bundle.  If followed by a\r
+       list of references, only references matching those given are\r
+       printed out.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+unbundle &lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+       Passes the objects in the bundle to <emphasis>git-index-pack</emphasis>\r
+       for storage in the repository, then prints the names of all\r
+       defined references. If a reflist is given, only references\r
+       matching those in the given list are printed. This command is\r
+       really plumbing, intended to be called only by <emphasis>git-fetch</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+[git-rev-list-args&#8230;]\r
+</term>\r
+<listitem>\r
+<simpara>\r
+       A list of arguments, acceptable to <emphasis>git-rev-parse</emphasis> and\r
+       <emphasis>git-rev-list</emphasis>, that specify the specific objects and references\r
+       to transport.  For example, "master~10..master" causes the\r
+       current master reference to be packaged along with all objects\r
+       added since its 10th ancestor commit.  There is no explicit\r
+       limit to the number of references and objects that may be\r
+       packaged.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+[refname&#8230;]\r
+</term>\r
+<listitem>\r
+<simpara>\r
+       A list of references used to limit the references reported as\r
+       available. This is principally of use to <emphasis>git-fetch</emphasis>, which\r
+       expects to receive only those references asked for and not\r
+       necessarily everything in the pack (in this case, <emphasis>git-bundle</emphasis> is\r
+       acting like <emphasis>git-fetch-pack</emphasis>).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_specifying_references">\r
+<title>SPECIFYING REFERENCES</title>\r
+<simpara><emphasis>git-bundle</emphasis> will only package references that are shown by\r
+<emphasis>git-show-ref</emphasis>: this includes heads, tags, and remote heads.  References\r
+such as master<subscript>1 cannot be packaged, but are perfectly suitable for\r
+defining the basis.  More than one reference may be packaged, and more\r
+than one basis can be specified.  The objects packaged are those not\r
+contained in the union of the given bases.  Each basis can be\r
+specified explicitly (e.g., ^master</subscript>10), or implicitly (e.g.,\r
+master~10..master, --since=10.days.ago master).</simpara>\r
+<simpara>It is very important that the basis used be held by the destination.\r
+It is okay to err on the side of conservatism, causing the bundle file\r
+to contain objects already in the destination as these are ignored\r
+when unpacking at the destination.</simpara>\r
+</simplesect>\r
+<simplesect id="_example">\r
+<title>EXAMPLE</title>\r
+<simpara>Assume you want to transfer the history from a repository R1 on machine A\r
+to another repository R2 on machine B.\r
+For whatever reason, direct connection between A and B is not allowed,\r
+but we can move data from A to B via some mechanism (CD, email, etc).\r
+We want to update R2 with developments made on branch master in R1.</simpara>\r
+<simpara>To bootstrap the process, you can first create a bundle that doesn&#8217;t have\r
+any basis. You can use a tag to remember up to what commit you sent out\r
+in order to make it easy to later update the other repository with\r
+incremental bundle,</simpara>\r
+<literallayout>machineA$ cd R1\r
+machineA$ git bundle create file.bdl master\r
+machineA$ git tag -f lastR2bundle master</literallayout>\r
+<simpara>Then you sneakernet file.bdl to the target machine B. Because you don&#8217;t\r
+have to have any object to extract objects from such a bundle, not only\r
+you can fetch/pull from a bundle, you can clone from it as if it was a\r
+remote repository.</simpara>\r
+<literallayout>machineB$ git clone /home/me/tmp/file.bdl R2</literallayout>\r
+<simpara>This will define a remote called "origin" in the resulting repository that\r
+lets you fetch and pull from the bundle. $GIT_DIR/config file in R2 may\r
+have an entry like this:</simpara>\r
+<literallayout>[remote "origin"]\r
+    url = /home/me/tmp/file.bdl\r
+    fetch = refs/heads/*:refs/remotes/origin/*</literallayout>\r
+<simpara>You can fetch/pull to update the resulting mine.git repository after\r
+replacing the bundle you store at /home/me/tmp/file.bdl with incremental\r
+updates from here on.</simpara>\r
+<simpara>After working more in the original repository, you can create an\r
+incremental bundle to update the other:</simpara>\r
+<literallayout>machineA$ cd R1\r
+machineA$ git bundle create file.bdl lastR2bundle..master\r
+machineA$ git tag -f lastR2bundle master</literallayout>\r
+<simpara>and sneakernet it to the other machine to replace /home/me/tmp/file.bdl,\r
+and pull from it.</simpara>\r
+<literallayout>machineB$ cd R2\r
+machineB$ git pull</literallayout>\r
+<simpara>If you know up to what commit the intended recipient repository should\r
+have the necessary objects for, you can use that knowledge to specify the\r
+basis, giving a cut-off point to limit the revisions and objects that go\r
+in the resulting bundle. The previous example used lastR2bundle tag\r
+for this purpose, but you can use other options you would give to\r
+the <xref linkend="git-log(1)"/> command. Here are more examples:</simpara>\r
+<simpara>You can use a tag that is present in both.</simpara>\r
+<literallayout>$ git bundle create mybundle v1.0.0..master</literallayout>\r
+<simpara>You can use a basis based on time.</simpara>\r
+<literallayout>$ git bundle create mybundle --since=10.days master</literallayout>\r
+<simpara>Or you can use the number of commits.</simpara>\r
+<literallayout>$ git bundle create mybundle -10 master</literallayout>\r
+<simpara>You can run <literal>git-bundle verify</literal> to see if you can extract from a bundle\r
+that was created with a basis.</simpara>\r
+<literallayout>$ git bundle verify mybundle</literallayout>\r
+<simpara>This will list what commits you must have in order to extract from the\r
+bundle and will error out if you don&#8217;t have them.</simpara>\r
+<simpara>A bundle from a recipient repository&#8217;s point of view is just like a\r
+regular repository it fetches/pulls from. You can for example map\r
+refs, like this example, when fetching:</simpara>\r
+<literallayout>$ git fetch mybundle master:localRef</literallayout>\r
+<simpara>Or see what refs it offers.</simpara>\r
+<literallayout>$ git ls-remote mybundle</literallayout>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Mark Levedahl &lt;<ulink url="mailto:mdl123@verizon.net">mdl123@verizon.net</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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-cat-file.html.xml b/doc/source/en/TortoiseGit/git_doc/git-cat-file.html.xml
new file mode 100644 (file)
index 0000000..5d6ec03
--- /dev/null
@@ -0,0 +1,158 @@
+<?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-cat-file(1)">\r
+<articleinfo>\r
+    <title>git-cat-file(1)</title>\r
+        <indexterm>\r
+                <primary>git-cat-file(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-cat-file - Provide content or type/size information for repository objects</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git cat-file</emphasis> [-t | -s | -e | -p | &lt;type&gt;] &lt;object&gt;\r
+<emphasis>git cat-file</emphasis> [--batch | --batch-check] &lt; &lt;list-of-objects&gt;</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>In the first form, provides content or type of objects in the repository. The\r
+type is required unless <emphasis>-t</emphasis> or <emphasis>-p</emphasis> is used to find the object type, or <emphasis>-s</emphasis>\r
+is used to find the object size.</simpara>\r
+<simpara>In the second form, a list of object (separated by LFs) is provided on stdin,\r
+and the SHA1, type, and size of each object is printed on stdout.</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
+        The name of the object to show.\r
+        For a more complete list of ways to spell object names, see\r
+        "SPECIFYING REVISIONS" section in <xref linkend="git-rev-parse(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-t\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of the content, show the object type identified by\r
+        &lt;object&gt;.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-s\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of the content, show the object size identified by\r
+        &lt;object&gt;.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-e\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Suppress all output; instead exit with zero status if &lt;object&gt;\r
+        exists and is a valid object.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-p\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Pretty-print the contents of &lt;object&gt; based on its type.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;type&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Typically this matches the real type of &lt;object&gt; but asking\r
+        for a type that can trivially be dereferenced from the given\r
+        &lt;object&gt; is also permitted.  An example is to ask for a\r
+        "tree" with &lt;object&gt; being a commit object that contains it,\r
+        or to ask for a "blob" with &lt;object&gt; being a tag object that\r
+        points at it.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--batch\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Print the SHA1, type, size, and contents of each object provided on\r
+        stdin. May not be combined with any other options or arguments.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--batch-check\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Print the SHA1, type, and size of each object provided on stdin. May not be\r
+        combined with any other options or arguments.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_output">\r
+<title>OUTPUT</title>\r
+<simpara>If <emphasis>-t</emphasis> is specified, one of the &lt;type&gt;.</simpara>\r
+<simpara>If <emphasis>-s</emphasis> is specified, the size of the &lt;object&gt; in bytes.</simpara>\r
+<simpara>If <emphasis>-e</emphasis> is specified, no output.</simpara>\r
+<simpara>If <emphasis>-p</emphasis> is specified, the contents of &lt;object&gt; are pretty-printed.</simpara>\r
+<simpara>If &lt;type&gt; is specified, the raw (though uncompressed) contents of the &lt;object&gt;\r
+will be returned.</simpara>\r
+<simpara>If <emphasis>--batch</emphasis> is specified, output of the following form is printed for each\r
+object specified on stdin:</simpara>\r
+<literallayout>&lt;sha1&gt; SP &lt;type&gt; SP &lt;size&gt; LF\r
+&lt;contents&gt; LF</literallayout>\r
+<simpara>If <emphasis>--batch-check</emphasis> is specified, output of the following form is printed for\r
+each object specified on stdin:</simpara>\r
+<literallayout>&lt;sha1&gt; SP &lt;type&gt; SP &lt;size&gt; LF</literallayout>\r
+<simpara>For both <emphasis>--batch</emphasis> and <emphasis>--batch-check</emphasis>, output of the following form is printed\r
+for each object specified on stdin that does not exist in the repository:</simpara>\r
+<literallayout>&lt;object&gt; SP missing LF</literallayout>\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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-check-attr.html.xml b/doc/source/en/TortoiseGit/git_doc/git-check-attr.html.xml
new file mode 100644 (file)
index 0000000..63ea583
--- /dev/null
@@ -0,0 +1,176 @@
+<?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-check-attr(1)">\r
+<articleinfo>\r
+    <title>git-check-attr(1)</title>\r
+        <indexterm>\r
+                <primary>git-check-attr(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-check-attr - Display gitattributes information</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git check-attr</emphasis> attr&#8230; [--] pathname&#8230;\r
+<emphasis>git check-attr</emphasis> --stdin [-z] attr&#8230; &lt; &lt;list-of-paths&gt;</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>For every pathname, this command will list if each attr is <emphasis>unspecified</emphasis>,\r
+<emphasis>set</emphasis>, or <emphasis>unset</emphasis> as a gitattribute on that pathname.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+--stdin\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Read file names from stdin instead of from the command-line.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-z\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Only meaningful with <literal>--stdin</literal>; paths are separated with\r
+        NUL character instead of LF.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Interpret all preceding arguments as attributes, and all following\r
+        arguments as path names. If not supplied, only the first argument will\r
+        be treated as an attribute.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_output">\r
+<title>OUTPUT</title>\r
+<simpara>The output is of the form:\r
+&lt;path&gt; COLON SP &lt;attribute&gt; COLON SP &lt;info&gt; LF</simpara>\r
+<simpara>Where &lt;path&gt; is the path of a file being queried, &lt;attribute&gt; is an attribute\r
+being queried and &lt;info&gt; can be either:</simpara>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+<emphasis>unspecified</emphasis>\r
+</term>\r
+<listitem>\r
+<simpara>\r
+when the attribute is not defined for the path.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<emphasis>unset</emphasis>\r
+</term>\r
+<listitem>\r
+<simpara>\r
+when the attribute is defined to false.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+<emphasis>set</emphasis>\r
+</term>\r
+<listitem>\r
+<simpara>\r
+when the attribute is defined to true.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;value&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+when a value has been assigned to the attribute.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>EXAMPLES</title>\r
+<simpara>In the examples, the following <emphasis>.gitattributes</emphasis> file is used:</simpara>\r
+<literallayout>*.java diff=java -crlf myAttr\r
+NoMyAttr.java !myAttr\r
+README caveat=unspecified</literallayout>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+Listing a single attribute:\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<literallayout>$ git check-attr diff org/example/MyClass.java\r
+org/example/MyClass.java: diff: java</literallayout>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+Listing multiple attributes for a file:\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<literallayout>$ git check-attr crlf diff myAttr -- org/example/MyClass.java\r
+org/example/MyClass.java: crlf: unset\r
+org/example/MyClass.java: diff: java\r
+org/example/MyClass.java: myAttr: set</literallayout>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+Listing attribute for multiple files:\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<literallayout>$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java\r
+org/example/MyClass.java: myAttr: set\r
+org/example/NoMyAttr.java: myAttr: unspecified</literallayout>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+Not all values are equally unambiguous:\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<literallayout>$ git check-attr caveat README\r
+README: caveat: unspecified</literallayout>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="gitattributes(5)"/>.</simpara>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Junio C Hamano &lt;<ulink url="mailto:gitster@pobox.com">gitster@pobox.com</ulink>&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_documentation">\r
+<title>Documentation</title>\r
+<simpara>Documentation by James Bowes.</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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-check-ref-format.html.xml b/doc/source/en/TortoiseGit/git_doc/git-check-ref-format.html.xml
new file mode 100644 (file)
index 0000000..0cd4b30
--- /dev/null
@@ -0,0 +1,86 @@
+<?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-check-ref-format(1)">\r
+<articleinfo>\r
+    <title>git-check-ref-format(1)</title>\r
+        <indexterm>\r
+                <primary>git-check-ref-format(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-check-ref-format - Make sure ref name is well formed</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara><emphasis>git check-ref-format</emphasis> &lt;refname&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Checks if a given <emphasis>refname</emphasis> is acceptable, and exits non-zero if\r
+it is not.</simpara>\r
+<simpara>A reference is used in git to specify branches and tags.  A\r
+branch head is stored under <literal>$GIT_DIR/refs/heads</literal> directory, and\r
+a tag is stored under <literal>$GIT_DIR/refs/tags</literal> directory.  git\r
+imposes the following rules on how refs are named:</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+It can include slash <literal>/</literal> for hierarchical (directory)\r
+  grouping, but no slash-separated component can begin with a\r
+  dot <literal>.</literal>;\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+It cannot have two consecutive dots <literal>..</literal> anywhere;\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+It cannot have ASCII control character (i.e. bytes whose\r
+  values are lower than \040, or \177 <literal>DEL</literal>), space, tilde <literal>~</literal>,\r
+  caret <literal>&#94;</literal>, colon <literal>:</literal>, question-mark <literal>?</literal>, asterisk <literal>*</literal>,\r
+  or open bracket <literal>[</literal> anywhere;\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+It cannot end with a slash <literal>/</literal>.\r
+</simpara>\r
+</listitem>\r
+</orderedlist>\r
+<simpara>These rules makes it easy for shell script based tools to parse\r
+refnames, pathname expansion by the shell when a refname is used\r
+unquoted (by mistake), and also avoids ambiguities in certain\r
+refname expressions (see <xref linkend="git-rev-parse(1)"/>).  Namely:</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+double-dot <literal>..</literal> are often used as in <literal>ref1..ref2</literal>, and in some\r
+  context this notation means <literal>&#94;ref1 ref2</literal> (i.e. not in\r
+  ref1 and in ref2).\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+tilde <literal>~</literal> and caret <literal>&#94;</literal> are used to introduce postfix\r
+  <emphasis>nth parent</emphasis> and <emphasis>peel onion</emphasis> operation.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+colon <literal>:</literal> is used as in <literal>srcref:dstref</literal> to mean "use srcref&#8217;s\r
+  value and store it in dstref" in fetch and push operations.\r
+  It may also be used to select a specific object such as with\r
+  <emphasis>git-cat-file</emphasis>: "git cat-file blob v1.3.3:refs.c".\r
+</simpara>\r
+</listitem>\r
+</orderedlist>\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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-checkout-index.html.xml b/doc/source/en/TortoiseGit/git_doc/git-checkout-index.html.xml
new file mode 100644 (file)
index 0000000..6eecfad
--- /dev/null
@@ -0,0 +1,283 @@
+<?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-checkout-index(1)">\r
+<articleinfo>\r
+    <title>git-checkout-index(1)</title>\r
+        <indexterm>\r
+                <primary>git-checkout-index(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-checkout-index - Copy files from the index to the working tree</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git checkout-index</emphasis> [-u] [-q] [-a] [-f] [-n] [--prefix=&lt;string&gt;]\r
+                   [--stage=&lt;number&gt;|all]\r
+                   [--temp]\r
+                   [-z] [--stdin]\r
+                   [--] [&lt;file&gt;]\*</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Will copy all files listed from the index to the working directory\r
+(not overwriting existing files).</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-u\r
+</term>\r
+<term>\r
+--index\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        update stat information for the checked out entries in\r
+        the index file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-q\r
+</term>\r
+<term>\r
+--quiet\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        be quiet if files exist or are not in the index\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-f\r
+</term>\r
+<term>\r
+--force\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        forces overwrite of existing files\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-a\r
+</term>\r
+<term>\r
+--all\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        checks out all files in the index.  Cannot be used\r
+        together with explicit filenames.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-n\r
+</term>\r
+<term>\r
+--no-create\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Don&#8217;t checkout new files, only refresh files already checked\r
+        out.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--prefix=&lt;string&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When creating files, prepend &lt;string&gt; (usually a directory\r
+        including a trailing /)\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--stage=&lt;number&gt;|all\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of checking out unmerged entries, copy out the\r
+        files from named stage.  &lt;number&gt; must be between 1 and 3.\r
+        Note: --stage=all automatically implies --temp.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--temp\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of copying the files to the working directory\r
+        write the content to temporary files.  The temporary name\r
+        associations will be written to stdout.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--stdin\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of taking list of paths from the command line,\r
+        read list of paths from the standard input.  Paths are\r
+        separated by LF (i.e. one path per line) by default.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-z\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Only meaningful with <literal>--stdin</literal>; paths are separated with\r
+        NUL character instead of LF.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Do not interpret any more arguments as options.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+<simpara>The order of the flags used to matter, but not anymore.</simpara>\r
+<simpara>Just doing <literal>git checkout-index</literal> does nothing. You probably meant\r
+<literal>git checkout-index -a</literal>. And if you want to force it, you want\r
+<literal>git checkout-index -f -a</literal>.</simpara>\r
+<simpara>Intuitiveness is not the goal here. Repeatability is. The reason for\r
+the "no arguments means no work" behavior is that from scripts you are\r
+supposed to be able to do:</simpara>\r
+<literallayout>$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --</literallayout>\r
+<simpara>which will force all existing <literal>*.h</literal> files to be replaced with their\r
+cached copies. If an empty command line implied "all", then this would\r
+force-refresh everything in the index, which was not the point.  But\r
+since <emphasis>git-checkout-index</emphasis> accepts --stdin it would be faster to use:</simpara>\r
+<literallayout>$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin</literallayout>\r
+<simpara>The <literal>--</literal> is just a good idea when you know the rest will be filenames;\r
+it will prevent problems with a filename of, for example,  <literal>-a</literal>.\r
+Using <literal>--</literal> is probably a good policy in scripts.</simpara>\r
+</simplesect>\r
+<simplesect id="_using_temp_or_stage_all">\r
+<title>Using --temp or --stage=all</title>\r
+<simpara>When <literal>--temp</literal> is used (or implied by <literal>--stage=all</literal>)\r
+<emphasis>git-checkout-index</emphasis> will create a temporary file for each index\r
+entry being checked out.  The index will not be updated with stat\r
+information.  These options can be useful if the caller needs all\r
+stages of all unmerged entries so that the unmerged files can be\r
+processed by an external merge tool.</simpara>\r
+<simpara>A listing will be written to stdout providing the association of\r
+temporary file names to tracked path names.  The listing format\r
+has two variations:</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+tempname TAB path RS\r
+</simpara>\r
+<simpara>The first format is what gets used when <literal>--stage</literal> is omitted or\r
+is not <literal>--stage=all</literal>. The field tempname is the temporary file\r
+name holding the file content and path is the tracked path name in\r
+the index.  Only the requested entries are output.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+stage1temp SP stage2temp SP stage3tmp TAB path RS\r
+</simpara>\r
+<simpara>The second format is what gets used when <literal>--stage=all</literal>.  The three\r
+stage temporary fields (stage1temp, stage2temp, stage3temp) list the\r
+name of the temporary file if there is a stage entry in the index\r
+or <literal>.</literal> if there is no stage entry.  Paths which only have a stage 0\r
+entry will always be omitted from the output.</simpara>\r
+</listitem>\r
+</orderedlist>\r
+<simpara>In both formats RS (the record separator) is newline by default\r
+but will be the null byte if -z was passed on the command line.\r
+The temporary file names are always safe strings; they will never\r
+contain directory separators or whitespace characters.  The path\r
+field is always relative to the current directory and the temporary\r
+file names are always relative to the top level directory.</simpara>\r
+<simpara>If the object being copied out to a temporary file is a symbolic\r
+link the content of the link will be written to a normal file.  It is\r
+up to the end-user or the Porcelain to make use of this information.</simpara>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>EXAMPLES</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+To update and refresh only the files already checked out\r
+</term>\r
+<listitem>\r
+<literallayout>$ git checkout-index -n -f -a &amp;&amp; git update-index --ignore-missing --refresh</literallayout>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Using <emphasis>git-checkout-index</emphasis> to "export an entire tree"\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The prefix ability basically makes it trivial to use\r
+        <emphasis>git-checkout-index</emphasis> as an "export as tree" function.\r
+        Just read the desired tree into the index, and do:\r
+</simpara>\r
+<literallayout>$ git checkout-index --prefix=git-export-dir/ -a</literallayout>\r
+<simpara><literal>git checkout-index</literal> will "export" the index into the specified\r
+directory.</simpara>\r
+<simpara>The final "/" is important. The exported name is literally just\r
+prefixed with the specified string.  Contrast this with the\r
+following example.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Export files with a prefix\r
+</term>\r
+<listitem>\r
+<literallayout>$ git checkout-index --prefix=.merged- Makefile</literallayout>\r
+<simpara>This will check out the currently cached copy of <literal>Makefile</literal>\r
+into the file <literal>.merged-Makefile</literal>.</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,\r
+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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-checkout.html.xml b/doc/source/en/TortoiseGit/git_doc/git-checkout.html.xml
new file mode 100644 (file)
index 0000000..2712808
--- /dev/null
@@ -0,0 +1,335 @@
+<?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-checkout(1)">\r
+<articleinfo>\r
+    <title>git-checkout(1)</title>\r
+        <indexterm>\r
+                <primary>git-checkout(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-checkout - Checkout a branch or paths to the working tree</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git checkout</emphasis> [-q] [-f] [--track | --no-track] [-b &lt;new_branch&gt; [-l]] [-m] [&lt;branch&gt;]\r
+<emphasis>git checkout</emphasis> [-f|--ours|--theirs|-m|--conflict=&lt;style&gt;] [&lt;tree-ish&gt;] [--] &lt;paths&gt;&#8230;</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>When &lt;paths&gt; are not given, this command switches branches by\r
+updating the index and working tree to reflect the specified\r
+branch, &lt;branch&gt;, and updating HEAD to be &lt;branch&gt; or, if\r
+specified, &lt;new_branch&gt;.  Using -b will cause &lt;new_branch&gt; to\r
+be created; in this case you can use the --track or --no-track\r
+options, which will be passed to <literal>git branch</literal>.</simpara>\r
+<simpara>As a convenience, --track will default to create a branch whose\r
+name is constructed from the specified branch name by stripping\r
+the first namespace level.</simpara>\r
+<simpara>When &lt;paths&gt; are given, this command does <emphasis role="strong">not</emphasis> switch\r
+branches.  It updates the named paths in the working tree from\r
+the index file, or from a named &lt;tree-ish&gt; (most often a commit).  In\r
+this case, the <literal>-b</literal> options is meaningless and giving\r
+either of them results in an error.  &lt;tree-ish&gt; argument can be\r
+used to specify a specific tree-ish (i.e. commit, tag or tree)\r
+to update the index for the given paths before updating the\r
+working tree.</simpara>\r
+<simpara>The index may contain unmerged entries after a failed merge.  By\r
+default, if you try to check out such an entry from the index, the\r
+checkout operation will fail and nothing will be checked out.\r
+Using -f will ignore these unmerged entries.  The contents from a\r
+specific side of the merge can be checked out of the index by\r
+using --ours or --theirs.  With -m, changes made to the working tree\r
+file can be discarded to recreate the original conflicted merge result.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-q\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Quiet, suppress feedback messages.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-f\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When switching branches, proceed even if the index or the\r
+        working tree differs from HEAD.  This is used to throw away\r
+        local changes.\r
+</simpara>\r
+<simpara>When checking out paths from the index, do not fail upon unmerged\r
+entries; instead, unmerged entries are ignored.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--ours\r
+</term>\r
+<term>\r
+--theirs\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When checking out paths from the index, check out stage #2\r
+        (<emphasis>ours</emphasis>) or #3 (<emphasis>theirs</emphasis>) for unmerged paths.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-b\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Create a new branch named &lt;new_branch&gt; and start it at\r
+        &lt;branch&gt;.  The new branch name must pass all checks defined\r
+        by <xref linkend="git-check-ref-format(1)"/>.  Some of these checks\r
+        may restrict the characters allowed in a branch name.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-t\r
+</term>\r
+<term>\r
+--track\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When creating a new branch, set up configuration so that <emphasis>git-pull</emphasis>\r
+        will automatically retrieve data from the start point, which must be\r
+        a branch. Use this if you always pull from the same upstream branch\r
+        into the new branch, and if you don&#8217;t want to use "git pull\r
+        &lt;repository&gt; &lt;refspec&gt;" explicitly. This behavior is the default\r
+        when the start point is a remote branch. Set the\r
+        branch.autosetupmerge configuration variable to <literal>false</literal> if you want\r
+        <emphasis>git-checkout</emphasis> and <emphasis>git-branch</emphasis> to always behave as if <emphasis>--no-track</emphasis> were\r
+        given. Set it to <literal>always</literal> if you want this behavior when the\r
+        start-point is either a local or remote branch.\r
+</simpara>\r
+<simpara>If no <emphasis>-b</emphasis> option was given, the name of the new branch will be\r
+derived from the remote branch, by attempting to guess the name\r
+of the branch on remote system.  If "remotes/" or "refs/remotes/"\r
+are prefixed, it is stripped away, and then the part up to the\r
+next slash (which would be the nickname of the remote) is removed.\r
+This would tell us to use "hack" as the local branch when branching\r
+off of "origin/hack" (or "remotes/origin/hack", or even\r
+"refs/remotes/origin/hack").  If the given name has no slash, or the above\r
+guessing results in an empty name, the guessing is aborted.  You can\r
+explicitly give a name with <emphasis>-b</emphasis> in such a case.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-track\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Ignore the branch.autosetupmerge configuration variable.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-l\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Create the new branch&#8217;s reflog.  This activates recording of\r
+        all changes made to the branch ref, enabling use of date\r
+        based sha1 expressions such as "&lt;branchname&gt;@{yesterday}".\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-m\r
+</term>\r
+<term>\r
+--merge\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When switching branches,\r
+        if you have local modifications to one or more files that\r
+        are different between the current branch and the branch to\r
+        which you are switching, the command refuses to switch\r
+        branches in order to preserve your modifications in context.\r
+        However, with this option, a three-way merge between the current\r
+        branch, your working tree contents, and the new branch\r
+        is done, and you will be on the new branch.\r
+</simpara>\r
+<simpara>When a merge conflict happens, the index entries for conflicting\r
+paths are left unmerged, and you need to resolve the conflicts\r
+and mark the resolved paths with <literal>git add</literal> (or <literal>git rm</literal> if the merge\r
+should result in deletion of the path).</simpara>\r
+<simpara>When checking out paths from the index, this option lets you recreate\r
+the conflicted merge in the specified paths.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--conflict=&lt;style&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The same as --merge option above, but changes the way the\r
+        conflicting hunks are presented, overriding the\r
+        merge.conflictstyle configuration variable.  Possible values are\r
+        "merge" (default) and "diff3" (in addition to what is shown by\r
+        "merge" style, shows the original contents).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;new_branch&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Name for the new branch.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;branch&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Branch to checkout; may be any object ID that resolves to a\r
+        commit.  Defaults to HEAD.\r
+</simpara>\r
+<simpara>When this parameter names a non-branch (but still a valid commit object),\r
+your HEAD becomes <emphasis>detached</emphasis>.</simpara>\r
+<simpara>As a special case, the "<literal>@{-N}</literal>" syntax for the N-th last branch\r
+checks out the branch (instead of detaching).  You may also specify\r
+"<literal>-</literal>" which is synonymous with "<literal>@{-1}</literal>".</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_detached_head">\r
+<title>Detached HEAD</title>\r
+<simpara>It is sometimes useful to be able to <emphasis>checkout</emphasis> a commit that is\r
+not at the tip of one of your branches.  The most obvious\r
+example is to check out the commit at a tagged official release\r
+point, like this:</simpara>\r
+<literallayout>$ git checkout v2.6.18</literallayout>\r
+<simpara>Earlier versions of git did not allow this and asked you to\r
+create a temporary branch using <literal>-b</literal> option, but starting from\r
+version 1.5.0, the above command <emphasis>detaches</emphasis> your HEAD from the\r
+current branch and directly point at the commit named by the tag\r
+(<literal>v2.6.18</literal> in the above example).</simpara>\r
+<simpara>You can use usual git commands while in this state.  You can use\r
+<literal>git reset --hard $othercommit</literal> to further move around, for\r
+example.  You can make changes and create a new commit on top of\r
+a detached HEAD.  You can even create a merge by using <literal>git\r
+merge $othercommit</literal>.</simpara>\r
+<simpara>The state you are in while your HEAD is detached is not recorded\r
+by any branch (which is natural --- you are not on any branch).\r
+What this means is that you can discard your temporary commits\r
+and merges by switching back to an existing branch (e.g. <literal>git\r
+checkout master</literal>), and a later <literal>git prune</literal> or <literal>git gc</literal> would\r
+garbage-collect them.  If you did this by mistake, you can ask\r
+the reflog for HEAD where you were, e.g.</simpara>\r
+<literallayout>$ git log -g -2 HEAD</literallayout>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>EXAMPLES</title>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+The following sequence checks out the <literal>master</literal> branch, reverts\r
+the <literal>Makefile</literal> to two revisions back, deletes hello.c by\r
+mistake, and gets it back from the index.\r
+</simpara>\r
+<literallayout>$ git checkout master             <co id="CO1-1"/>\r
+$ git checkout master~2 Makefile  <co id="CO1-2"/>\r
+$ rm -f hello.c\r
+$ git checkout hello.c            <co id="CO1-3"/></literallayout>\r
+<calloutlist>\r
+<callout arearefs="CO1-1">\r
+<simpara>\r
+switch branch\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO1-2">\r
+<simpara>\r
+take out a file out of other commit\r
+</simpara>\r
+</callout>\r
+<callout arearefs="CO1-3">\r
+<simpara>\r
+restore hello.c from HEAD of current branch\r
+</simpara>\r
+<simpara>If you have an unfortunate branch that is named <literal>hello.c</literal>, this\r
+step would be confused as an instruction to switch to that branch.\r
+You should instead write:</simpara>\r
+<literallayout>$ git checkout -- hello.c</literallayout>\r
+</callout>\r
+</calloutlist>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+After working in a wrong branch, switching to the correct\r
+branch would be done using:\r
+</simpara>\r
+<literallayout>$ git checkout mytopic</literallayout>\r
+<simpara>However, your "wrong" branch and correct "mytopic" branch may\r
+differ in files that you have locally modified, in which case,\r
+the above checkout would fail like this:</simpara>\r
+<literallayout>$ git checkout mytopic\r
+fatal: Entry 'frotz' not uptodate. Cannot merge.</literallayout>\r
+<simpara>You can give the <literal>-m</literal> flag to the command, which would try a\r
+three-way merge:</simpara>\r
+<literallayout>$ git checkout -m mytopic\r
+Auto-merging frotz</literallayout>\r
+<simpara>After this three-way merge, the local modifications are <emphasis>not</emphasis>\r
+registered in your index file, so <literal>git diff</literal> would show you what\r
+changes you made since the tip of the new branch.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+When a merge conflict happens during switching branches with\r
+the <literal>-m</literal> option, you would see something like this:\r
+</simpara>\r
+<literallayout>$ git checkout -m mytopic\r
+Auto-merging frotz\r
+ERROR: Merge conflict in frotz\r
+fatal: merge program failed</literallayout>\r
+<simpara>At this point, <literal>git diff</literal> shows the changes cleanly merged as in\r
+the previous example, as well as the changes in the conflicted\r
+files.  Edit and resolve the conflict and mark it resolved with\r
+<literal>git add</literal> as usual:</simpara>\r
+<literallayout>$ edit frotz\r
+$ git add frotz</literallayout>\r
+</listitem>\r
+</orderedlist>\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 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-cherry-pick.html.xml b/doc/source/en/TortoiseGit/git_doc/git-cherry-pick.html.xml
new file mode 100644 (file)
index 0000000..06eb13b
--- /dev/null
@@ -0,0 +1,151 @@
+<?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-cherry-pick(1)">\r
+<articleinfo>\r
+    <title>git-cherry-pick(1)</title>\r
+        <indexterm>\r
+                <primary>git-cherry-pick(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-cherry-pick - Apply the change introduced by an existing commit</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara><emphasis>git cherry-pick</emphasis> [--edit] [-n] [-m parent-number] [-s] [-x] &lt;commit&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Given one existing commit, apply the change the patch introduces, and record a\r
+new commit that records it.  This requires your working tree to be clean (no\r
+modifications from the HEAD commit).</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+&lt;commit&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Commit to cherry-pick.\r
+        For a more complete list of ways to spell commits, see the\r
+        "SPECIFYING REVISIONS" section in <xref linkend="git-rev-parse(1)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-e\r
+</term>\r
+<term>\r
+--edit\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        With this option, <emphasis>git-cherry-pick</emphasis> will let you edit the commit\r
+        message prior to committing.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-x\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When recording the commit, append to the original commit\r
+        message a note that indicates which commit this change\r
+        was cherry-picked from.  Append the note only for cherry\r
+        picks without conflicts.  Do not use this option if\r
+        you are cherry-picking from your private branch because\r
+        the information is useless to the recipient.  If on the\r
+        other hand you are cherry-picking between two publicly\r
+        visible branches (e.g. backporting a fix to a\r
+        maintenance branch for an older release from a\r
+        development branch), adding this information can be\r
+        useful.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-r\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        It used to be that the command defaulted to do <literal>-x</literal>\r
+        described above, and <literal>-r</literal> was to disable it.  Now the\r
+        default is not to do <literal>-x</literal> so this option is a no-op.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-m parent-number\r
+</term>\r
+<term>\r
+--mainline parent-number\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Usually you cannot cherry-pick a merge because you do not know which\r
+        side of the merge should be considered the mainline.  This\r
+        option specifies the parent number (starting from 1) of\r
+        the mainline and allows cherry-pick to replay the change\r
+        relative to the specified parent.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-n\r
+</term>\r
+<term>\r
+--no-commit\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Usually the command automatically creates a commit.\r
+        This flag applies the change necessary to cherry-pick\r
+        the named commit to your working tree and the index,\r
+        but does not make the commit.  In addition, when this\r
+        option is used, your index does not have to match the\r
+        HEAD commit.  The cherry-pick is done against the\r
+        beginning state of your index.\r
+</simpara>\r
+<simpara>This is useful when cherry-picking more than one commits'\r
+effect to your index in a row.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-s\r
+</term>\r
+<term>\r
+--signoff\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Add Signed-off-by line at the end of the commit message.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Junio C Hamano &lt;<ulink url="mailto:gitster@pobox.com">gitster@pobox.com</ulink>&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_documentation">\r
+<title>Documentation</title>\r
+<simpara>Documentation by 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-cherry.html.xml b/doc/source/en/TortoiseGit/git_doc/git-cherry.html.xml
new file mode 100644 (file)
index 0000000..3a1b078
--- /dev/null
@@ -0,0 +1,108 @@
+<?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-cherry(1)">\r
+<articleinfo>\r
+    <title>git-cherry(1)</title>\r
+        <indexterm>\r
+                <primary>git-cherry(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-cherry - Find commits not merged upstream</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara><emphasis>git cherry</emphasis> [-v] [&lt;upstream&gt; [&lt;head&gt; [&lt;limit&gt;]]]</simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>The changeset (or "diff") of each commit between the fork-point and &lt;head&gt;\r
+is compared against each commit between the fork-point and &lt;upstream&gt;.\r
+The commits are compared with their <emphasis>patch id</emphasis>, obtained from\r
+the <emphasis>git-patch-id</emphasis> program.</simpara>\r
+<simpara>Every commit that doesn&#8217;t exist in the &lt;upstream&gt; branch\r
+has its id (sha1) reported, prefixed by a symbol.  The ones that have\r
+equivalent change already\r
+in the &lt;upstream&gt; branch are prefixed with a minus (-) sign, and those\r
+that only exist in the &lt;head&gt; branch are prefixed with a plus (+) symbol:</simpara>\r
+<literallayout class="monospaced">           __*__*__*__*__&gt; &lt;upstream&gt;\r
+          /\r
+fork-point\r
+          \__+__+__-__+__+__-__+__&gt; &lt;head&gt;</literallayout>\r
+<simpara>If a &lt;limit&gt; has been given then the commits along the &lt;head&gt; branch up\r
+to and including &lt;limit&gt; are not reported:</simpara>\r
+<literallayout class="monospaced">           __*__*__*__*__&gt; &lt;upstream&gt;\r
+          /\r
+fork-point\r
+          \__*__*__&lt;limit&gt;__-__+__&gt; &lt;head&gt;</literallayout>\r
+<simpara>Because <emphasis>git-cherry</emphasis> compares the changeset rather than the commit id\r
+(sha1), you can use <emphasis>git-cherry</emphasis> to find out if a commit you made locally\r
+has been applied &lt;upstream&gt; under a different commit id.  For example,\r
+this will happen if you&#8217;re feeding patches &lt;upstream&gt; via email rather\r
+than pushing or pulling commits directly.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-v\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Verbose.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;upstream&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Upstream branch to compare against.\r
+        Defaults to the first tracked remote branch, if available.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;head&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Working branch; defaults to HEAD.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;limit&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Do not report commits up to (and including) limit.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="git-patch-id(1)"/></simpara>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Junio C Hamano &lt;<ulink url="mailto:gitster@pobox.com">gitster@pobox.com</ulink>&gt;</simpara>\r
+</simplesect>\r
+<simplesect id="_documentation">\r
+<title>Documentation</title>\r
+<simpara>Documentation by 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-citool.html.xml b/doc/source/en/TortoiseGit/git_doc/git-citool.html.xml
new file mode 100644 (file)
index 0000000..81fb726
--- /dev/null
@@ -0,0 +1,40 @@
+<?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-citool(1)">\r
+<articleinfo>\r
+    <title>git-citool(1)</title>\r
+        <indexterm>\r
+                <primary>git-citool(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-citool - Graphical alternative to git-commit</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara><emphasis>git citool</emphasis></simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>A Tcl/Tk based graphical interface to review modified files, stage\r
+them into the index, enter a commit message and record the new\r
+commit onto the current branch.  This interface is an alternative\r
+to the less interactive <emphasis>git-commit</emphasis> program.</simpara>\r
+<simpara><emphasis>git-citool</emphasis> is actually a standard alias for <literal>git gui citool</literal>.\r
+See <xref linkend="git-gui(1)"/> for more details.</simpara>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Shawn O. Pearce &lt;<ulink url="mailto:spearce@spearce.org">spearce@spearce.org</ulink>&gt;.</simpara>\r
+</simplesect>\r
+<simplesect id="_documentation">\r
+<title>Documentation</title>\r
+<simpara>Documentation by Shawn O. Pearce &lt;<ulink url="mailto:spearce@spearce.org">spearce@spearce.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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-clean.html.xml b/doc/source/en/TortoiseGit/git_doc/git-clean.html.xml
new file mode 100644 (file)
index 0000000..8cff099
--- /dev/null
@@ -0,0 +1,115 @@
+<?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-clean(1)">\r
+<articleinfo>\r
+    <title>git-clean(1)</title>\r
+        <indexterm>\r
+                <primary>git-clean(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-clean - Remove untracked files from the working tree</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git clean</emphasis> [-d] [-f] [-n] [-q] [-x | -X] [--] &lt;path&gt;&#8230;</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Removes files unknown to git.  This allows to clean the working tree\r
+from files that are not under version control.  If the <emphasis>-x</emphasis> option is\r
+specified, ignored files are also removed, allowing to remove all\r
+build products.\r
+If any optional <literal>&lt;path&gt;&#8230;</literal> arguments are given, only those paths\r
+are affected.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-d\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Remove untracked directories in addition to untracked files.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-f\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If the git configuration specifies clean.requireForce as true,\r
+        <emphasis>git-clean</emphasis> will refuse to run unless given -f or -n.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-n\r
+</term>\r
+<term>\r
+--dry-run\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Don&#8217;t actually remove anything, just show what would be done.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-q\r
+</term>\r
+<term>\r
+--quiet\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Be quiet, only report errors, but not the files that are\r
+        successfully removed.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-x\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Don&#8217;t use the ignore rules.  This allows removing all untracked\r
+        files, including build products.  This can be used (possibly in\r
+        conjunction with <emphasis>git-reset</emphasis>) to create a pristine\r
+        working directory to test a clean build.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-X\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Remove only files ignored by git.  This may be useful to rebuild\r
+        everything from scratch, but keep manually created files.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_author">\r
+<title>Author</title>\r
+<simpara>Written by Pavel Roskin &lt;<ulink url="mailto:proski@gnu.org">proski@gnu.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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-clone.html.xml b/doc/source/en/TortoiseGit/git_doc/git-clone.html.xml
new file mode 100644 (file)
index 0000000..54a66bf
--- /dev/null
@@ -0,0 +1,447 @@
+<?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-clone(1)">\r
+<articleinfo>\r
+    <title>git-clone(1)</title>\r
+        <indexterm>\r
+                <primary>git-clone(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-clone - Clone a repository into a new directory</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git clone</emphasis> [--template=&lt;template_directory&gt;]\r
+          [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]\r
+          [-o &lt;name&gt;] [-u &lt;upload-pack&gt;] [--reference &lt;repository&gt;]\r
+          [--depth &lt;depth&gt;] [--] &lt;repository&gt; [&lt;directory&gt;]</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Clones a repository into a newly created directory, creates\r
+remote-tracking branches for each branch in the cloned repository\r
+(visible using <literal>git branch -r</literal>), and creates and checks out an initial\r
+branch equal to the cloned repository&#8217;s currently active branch.</simpara>\r
+<simpara>After the clone, a plain <literal>git fetch</literal> without arguments will update\r
+all the remote-tracking branches, and a <literal>git pull</literal> without\r
+arguments will in addition merge the remote master branch into the\r
+current master branch, if any.</simpara>\r
+<simpara>This default configuration is achieved by creating references to\r
+the remote branch heads under <literal>$GIT_DIR/refs/remotes/origin</literal> and\r
+by initializing <literal>remote.origin.url</literal> and <literal>remote.origin.fetch</literal>\r
+configuration variables.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+--local\r
+</term>\r
+<term>\r
+-l\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When the repository to clone from is on a local machine,\r
+        this flag bypasses normal "git aware" transport\r
+        mechanism and clones the repository by making a copy of\r
+        HEAD and everything under objects and refs directories.\r
+        The files under <literal>.git/objects/</literal> directory are hardlinked\r
+        to save space when possible.  This is now the default when\r
+        the source repository is specified with <literal>/path/to/repo</literal>\r
+        syntax, so it essentially is a no-op option.  To force\r
+        copying instead of hardlinking (which may be desirable\r
+        if you are trying to make a back-up of your repository),\r
+        but still avoid the usual "git aware" transport\r
+        mechanism, <literal>--no-hardlinks</literal> can be used.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-hardlinks\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Optimize the cloning process from a repository on a\r
+        local filesystem by copying files under <literal>.git/objects</literal>\r
+        directory.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--shared\r
+</term>\r
+<term>\r
+-s\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When the repository to clone is on the local machine,\r
+        instead of using hard links, automatically setup\r
+        .git/objects/info/alternates to share the objects\r
+        with the source repository.  The resulting repository\r
+        starts out without any object of its own.\r
+</simpara>\r
+<simpara><emphasis role="strong">NOTE</emphasis>: this is a possibly dangerous operation; do <emphasis role="strong">not</emphasis> use\r
+it unless you understand what it does. If you clone your\r
+repository using this option and then delete branches (or use any\r
+other git command that makes any existing commit unreferenced) in the\r
+source repository, some objects may become unreferenced (or dangling).\r
+These objects may be removed by normal git operations (such as <emphasis>git-commit</emphasis>)\r
+which automatically call <literal>git gc --auto</literal>. (See <xref linkend="git-gc(1)"/>.)\r
+If these objects are removed and were referenced by the cloned repository,\r
+then the cloned repository will become corrupt.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--reference &lt;repository&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If the reference repository is on the local machine\r
+        automatically setup .git/objects/info/alternates to\r
+        obtain objects from the reference repository.  Using\r
+        an already existing repository as an alternate will\r
+        require fewer objects to be copied from the repository\r
+        being cloned, reducing network and local storage costs.\r
+</simpara>\r
+<simpara><emphasis role="strong">NOTE</emphasis>: see NOTE to --shared option.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--quiet\r
+</term>\r
+<term>\r
+-q\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Operate quietly.  This flag is also passed to the &#8216;rsync&#8217;\r
+        command when given.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--verbose\r
+</term>\r
+<term>\r
+-v\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Display the progressbar, even in case the standard output is not\r
+        a terminal.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--no-checkout\r
+</term>\r
+<term>\r
+-n\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        No checkout of HEAD is performed after the clone is complete.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--bare\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Make a <emphasis>bare</emphasis> GIT repository.  That is, instead of\r
+        creating <literal>&lt;directory&gt;</literal> and placing the administrative\r
+        files in <literal>&lt;directory&gt;/.git</literal>, make the <literal>&lt;directory&gt;</literal>\r
+        itself the <literal>$GIT_DIR</literal>. This obviously implies the <literal>-n</literal>\r
+        because there is nowhere to check out the working tree.\r
+        Also the branch heads at the remote are copied directly\r
+        to corresponding local branch heads, without mapping\r
+        them to <literal>refs/remotes/origin/</literal>.  When this option is\r
+        used, neither remote-tracking branches nor the related\r
+        configuration variables are created.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--mirror\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Set up a mirror of the remote repository.  This implies --bare.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--origin &lt;name&gt;\r
+</term>\r
+<term>\r
+-o &lt;name&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Instead of using the remote name <emphasis>origin</emphasis> to keep track\r
+        of the upstream repository, use &lt;name&gt; instead.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--upload-pack &lt;upload-pack&gt;\r
+</term>\r
+<term>\r
+-u &lt;upload-pack&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When given, and the repository to clone from is accessed\r
+        via ssh, this specifies a non-default path for the command\r
+        run on the other end.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--template=&lt;template_directory&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Specify the directory from which templates will be used;\r
+        if unset the templates are taken from the installation\r
+        defined default, typically <literal>/usr/share/git-core/templates</literal>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--depth &lt;depth&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Create a <emphasis>shallow</emphasis> clone with a history truncated to the\r
+        specified number of revisions.  A shallow repository has a\r
+        number of limitations (you cannot clone or fetch from\r
+        it, nor push from nor into it), but is adequate if you\r
+        are only interested in the recent history of a large project\r
+        with a long history, and would want to send in fixes\r
+        as patches.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;repository&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The (possibly remote) repository to clone from.  See the\r
+        <link linkend="URLS">URLS</link> section below for more information on specifying\r
+        repositories.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;directory&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The name of a new directory to clone into.  The "humanish"\r
+        part of the source repository is used if no directory is\r
+        explicitly given ("repo" for "/path/to/repo.git" and "foo"\r
+        for "host.xz:foo/.git").  Cloning into an existing directory\r
+        is not allowed.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_git_urls_anchor_id_urls_xreflabel_urls">\r
+<title>GIT URLS<anchor id="URLS" xreflabel="[URLS]"/></title>\r
+<simpara>One of the following notations can be used\r
+to name the remote repository:</simpara>\r
+<informalexample>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+rsync://host.xz/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<ulink url="http://host.xz&#91;:port&#93;/path/to/repo.git/">http://host.xz&#91;:port&#93;/path/to/repo.git/</ulink>\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<ulink url="https://host.xz&#91;:port&#93;/path/to/repo.git/">https://host.xz&#91;:port&#93;/path/to/repo.git/</ulink>\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+git://host.xz&#91;:port&#93;/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+git://host.xz&#91;:port&#93;/~user/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+ssh://&#91;user@&#93;host.xz&#91;:port&#93;/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+ssh://&#91;user@&#93;host.xz/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+ssh://&#91;user@&#93;host.xz/~user/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+ssh://&#91;user@&#93;host.xz/~/path/to/repo.git\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+</informalexample>\r
+<simpara>SSH is the default transport protocol over the network.  You can\r
+optionally specify which user to log-in as, and an alternate,\r
+scp-like syntax is also supported.  Both syntaxes support\r
+username expansion, as does the native git protocol, but\r
+only the former supports port specification. The following\r
+three are identical to the last three above, respectively:</simpara>\r
+<informalexample>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+&#91;user@&#93;host.xz:/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+&#91;user@&#93;host.xz:~user/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+&#91;user@&#93;host.xz:path/to/repo.git\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+</informalexample>\r
+<simpara>To sync with a local directory, you can use:</simpara>\r
+<informalexample>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+/path/to/repo.git/\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<ulink url="file:///path/to/repo.git/">file:///path/to/repo.git/</ulink>\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+</informalexample>\r
+<simpara>They are equivalent, except the former implies --local option.</simpara>\r
+<simpara>If there are a large number of similarly-named remote repositories and\r
+you want to use a different format for them (such that the URLs you\r
+use will be rewritten into URLs that work), you can create a\r
+configuration section of the form:</simpara>\r
+<literallayout>        [url "&lt;actual url base&gt;"]\r
+                insteadOf = &lt;other url base&gt;</literallayout>\r
+<simpara>For example, with this:</simpara>\r
+<literallayout>        [url "git://git.host.xz/"]\r
+                insteadOf = host.xz:/path/to/\r
+                insteadOf = work:</literallayout>\r
+<simpara>a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be\r
+rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".</simpara>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>Examples</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+Clone from upstream\r
+</term>\r
+<listitem>\r
+<literallayout>$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6\r
+$ cd my2.6\r
+$ make</literallayout>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Make a local clone that borrows from the current directory, without checking things out\r
+</term>\r
+<listitem>\r
+<literallayout>$ git clone -l -s -n . ../copy\r
+$ cd ../copy\r
+$ git show-branch</literallayout>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Clone from upstream while borrowing from an existing local directory\r
+</term>\r
+<listitem>\r
+<literallayout>$ git clone --reference my2.6 \\r
+        git://git.kernel.org/pub/scm/.../linux-2.7 \\r
+        my2.7\r
+$ cd my2.7</literallayout>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Create a bare repository to publish your changes to the public\r
+</term>\r
+<listitem>\r
+<literallayout>$ git clone --bare -l /home/proj/.git /pub/scm/proj.git</literallayout>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Create a repository on the kernel.org machine that borrows from Linus\r
+</term>\r
+<listitem>\r
+<literallayout>$ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \\r
+    /pub/scm/.../me/subsys-2.6.git</literallayout>\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 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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-commit-tree.html.xml b/doc/source/en/TortoiseGit/git_doc/git-commit-tree.html.xml
new file mode 100644 (file)
index 0000000..657d499
--- /dev/null
@@ -0,0 +1,221 @@
+<?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-commit-tree(1)">\r
+<articleinfo>\r
+    <title>git-commit-tree(1)</title>\r
+        <indexterm>\r
+                <primary>git-commit-tree(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-commit-tree - Create a new commit object</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara><emphasis>git commit-tree</emphasis> &lt;tree&gt; [-p &lt;parent commit&gt;]\* &lt; changelog</simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>This is usually not what an end user wants to run directly.  See\r
+<xref linkend="git-commit(1)"/> instead.</simpara>\r
+<simpara>Creates a new commit object based on the provided tree object and\r
+emits the new commit object id on stdout.</simpara>\r
+<simpara>A commit object may have any number of parents. With exactly one\r
+parent, it is an ordinary commit. Having more than one parent makes\r
+the commit a merge between several lines of history. Initial (root)\r
+commits have no parents.</simpara>\r
+<simpara>While a tree represents a particular directory state of a working\r
+directory, a commit represents that state in "time", and explains how\r
+to get there.</simpara>\r
+<simpara>Normally a commit would identify a new "HEAD" state, and while git\r
+doesn&#8217;t care where you save the note about that state, in practice we\r
+tend to just write the result to the file that is pointed at by\r
+<literal>.git/HEAD</literal>, so that we can always see what the last committed\r
+state was.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+&lt;tree&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        An existing tree object\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-p &lt;parent commit&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Each <emphasis>-p</emphasis> indicates the id of a parent commit object.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_commit_information">\r
+<title>Commit Information</title>\r
+<simpara>A commit encapsulates:</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+all parent object ids\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+author name, email and date\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+committer name and email and the commit time.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simpara>While parent object ids are provided on the command line, author and\r
+committer information is taken from the following environment variables,\r
+if set:</simpara>\r
+<literallayout class="monospaced">GIT_AUTHOR_NAME\r
+GIT_AUTHOR_EMAIL\r
+GIT_AUTHOR_DATE\r
+GIT_COMMITTER_NAME\r
+GIT_COMMITTER_EMAIL\r
+GIT_COMMITTER_DATE\r
+EMAIL</literallayout>\r
+<simpara>(nb "&lt;", "&gt;" and "\n"s are stripped)</simpara>\r
+<simpara>In case (some of) these environment variables are not set, the information\r
+is taken from the configuration items user.name and user.email, or, if not\r
+present, system user name and fully qualified hostname.</simpara>\r
+<simpara>A commit comment is read from stdin. If a changelog\r
+entry is not provided via "&lt;" redirection, <emphasis>git-commit-tree</emphasis> will just wait\r
+for one to be entered and terminated with ^D.</simpara>\r
+</simplesect>\r
+<simplesect id="_diagnostics">\r
+<title>Diagnostics</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+You don&#8217;t exist. Go away!\r
+</term>\r
+<listitem>\r
+<simpara>\r
+    The passwd(5) gecos field couldn&#8217;t be read\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Your parents must have hated you!\r
+</term>\r
+<listitem>\r
+<simpara>\r
+    The passwd(5) gecos field is longer than a giant static buffer.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+Your sysadmin must hate you!\r
+</term>\r
+<listitem>\r
+<simpara>\r
+    The passwd(5) name field is longer than a giant static buffer.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_discussion">\r
+<title>Discussion</title>\r
+<simpara>At the core level, git is character encoding agnostic.</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+The pathnames recorded in the index and in the tree objects\r
+   are treated as uninterpreted sequences of non-NUL bytes.\r
+   What readdir(2) returns are what are recorded and compared\r
+   with the data git keeps track of, which in turn are expected\r
+   to be what lstat(2) and creat(2) accepts.  There is no such\r
+   thing as pathname encoding translation.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+The contents of the blob objects are uninterpreted sequences\r
+   of bytes.  There is no encoding translation at the core\r
+   level.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+The commit log messages are uninterpreted sequences of non-NUL\r
+   bytes.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simpara>Although we encourage that the commit log messages are encoded\r
+in UTF-8, both the core and git Porcelain are designed not to\r
+force UTF-8 on projects.  If all participants of a particular\r
+project find it more convenient to use legacy encodings, git\r
+does not forbid it.  However, there are a few things to keep in\r
+mind.</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+<emphasis>git-commit</emphasis> and <emphasis>git-commit-tree</emphasis> issues\r
+  a warning if the commit log message given to it does not look\r
+  like a valid UTF-8 string, unless you explicitly say your\r
+  project uses a legacy encoding.  The way to say this is to\r
+  have i18n.commitencoding in <literal>.git/config</literal> file, like this:\r
+</simpara>\r
+<literallayout>[i18n]\r
+        commitencoding = ISO-8859-1</literallayout>\r
+<simpara>Commit objects created with the above setting record the value\r
+of <literal>i18n.commitencoding</literal> in its <literal>encoding</literal> header.  This is to\r
+help other people who look at them later.  Lack of this header\r
+implies that the commit log message is encoded in UTF-8.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<emphasis>git-log</emphasis>, <emphasis>git-show</emphasis>, <emphasis>git-blame</emphasis> and friends look at the\r
+  <literal>encoding</literal> header of a commit object, and try to re-code the\r
+  log message into UTF-8 unless otherwise specified.  You can\r
+  specify the desired output encoding with\r
+  <literal>i18n.logoutputencoding</literal> in <literal>.git/config</literal> file, like this:\r
+</simpara>\r
+<literallayout>[i18n]\r
+        logoutputencoding = ISO-8859-1</literallayout>\r
+<simpara>If you do not have this configuration variable, the value of\r
+<literal>i18n.commitencoding</literal> is used instead.</simpara>\r
+</listitem>\r
+</orderedlist>\r
+<simpara>Note that we deliberately chose not to re-code the commit log\r
+message when a commit is made to force UTF-8 at the commit\r
+object level, because re-coding to UTF-8 is not necessarily a\r
+reversible operation.</simpara>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="git-write-tree(1)"/></simpara>\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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-commit.html.xml b/doc/source/en/TortoiseGit/git_doc/git-commit.html.xml
new file mode 100644 (file)
index 0000000..cbaca39
--- /dev/null
@@ -0,0 +1,575 @@
+<?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-commit(1)">\r
+<articleinfo>\r
+    <title>git-commit(1)</title>\r
+        <indexterm>\r
+                <primary>git-commit(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-commit - Record changes to the repository</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git commit</emphasis> [-a | --interactive] [-s] [-v] [-u&lt;mode&gt;] [--amend]\r
+           [(-c | -C) &lt;commit&gt;] [-F &lt;file&gt; | -m &lt;msg&gt;]\r
+           [--allow-empty] [--no-verify] [-e] [--author=&lt;author&gt;]\r
+           [--cleanup=&lt;mode&gt;] [--] [[-i | -o ]&lt;file&gt;&#8230;]</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>Stores the current contents of the index in a new commit along\r
+with a log message from the user describing the changes.</simpara>\r
+<simpara>The content to be added can be specified in several ways:</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+by using <emphasis>git-add</emphasis> to incrementally "add" changes to the\r
+   index before using the <emphasis>commit</emphasis> command (Note: even modified\r
+   files must be "added");\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+by using <emphasis>git-rm</emphasis> to remove files from the working tree\r
+   and the index, again before using the <emphasis>commit</emphasis> command;\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+by listing files as arguments to the <emphasis>commit</emphasis> command, in which\r
+   case the commit will ignore changes staged in the index, and instead\r
+   record the current content of the listed files (which must already\r
+   be known to git);\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+by using the -a switch with the <emphasis>commit</emphasis> command to automatically\r
+   "add" changes from all known files (i.e. all files that are already\r
+   listed in the index) and to automatically "rm" files in the index\r
+   that have been removed from the working tree, and then perform the\r
+   actual commit;\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+by using the --interactive switch with the <emphasis>commit</emphasis> command to decide one\r
+   by one which files should be part of the commit, before finalizing the\r
+   operation.  Currently, this is done by invoking <emphasis>git-add --interactive</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</orderedlist>\r
+<simpara>The <emphasis>git-status</emphasis> command can be used to obtain a\r
+summary of what is included by any of the above for the next\r
+commit by giving the same set of parameters you would give to\r
+this command.</simpara>\r
+<simpara>If you make a commit and then find a mistake immediately after\r
+that, you can recover from it with <emphasis>git-reset</emphasis>.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+-a\r
+</term>\r
+<term>\r
+--all\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Tell the command to automatically stage files that have\r
+        been modified and deleted, but new files you have not\r
+        told git about are not affected.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-C &lt;commit&gt;\r
+</term>\r
+<term>\r
+--reuse-message=&lt;commit&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Take an existing commit object, and reuse the log message\r
+        and the authorship information (including the timestamp)\r
+        when creating the commit.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-c &lt;commit&gt;\r
+</term>\r
+<term>\r
+--reedit-message=&lt;commit&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Like <emphasis>-C</emphasis>, but with <emphasis>-c</emphasis> the editor is invoked, so that\r
+        the user can further edit the commit message.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-F &lt;file&gt;\r
+</term>\r
+<term>\r
+--file=&lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Take the commit message from the given file.  Use <emphasis>-</emphasis> to\r
+        read the message from the standard input.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--author=&lt;author&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Override the author name used in the commit.  You can use the\r
+        standard <literal>A U Thor &lt;<ulink url="mailto:author@example.com">author@example.com</ulink>&gt;</literal> format.  Otherwise,\r
+        an existing commit that matches the given string and its author\r
+        name is used.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-m &lt;msg&gt;\r
+</term>\r
+<term>\r
+--message=&lt;msg&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Use the given &lt;msg&gt; as the commit message.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-t &lt;file&gt;\r
+</term>\r
+<term>\r
+--template=&lt;file&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Use the contents of the given file as the initial version\r
+        of the commit message. The editor is invoked and you can\r
+        make subsequent changes. If a message is specified using\r
+        the <literal>-m</literal> or <literal>-F</literal> options, this option has no effect. This\r
+        overrides the <literal>commit.template</literal> configuration variable.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-s\r
+</term>\r
+<term>\r
+--signoff\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Add Signed-off-by line by the committer at the end of the commit\r
+        log message.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-n\r
+</term>\r
+<term>\r
+--no-verify\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        This option bypasses the pre-commit and commit-msg hooks.\r
+        See also <xref linkend="githooks(5)"/>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--allow-empty\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Usually recording a commit that has the exact same tree as its\r
+        sole parent commit is a mistake, and the command prevents you\r
+        from making such a commit.  This option bypasses the safety, and\r
+        is primarily for use by foreign scm interface scripts.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--cleanup=&lt;mode&gt;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        This option sets how the commit message is cleaned up.\r
+        The  <emphasis>&lt;mode&gt;</emphasis> can be one of <emphasis>verbatim</emphasis>, <emphasis>whitespace</emphasis>, <emphasis>strip</emphasis>,\r
+        and <emphasis>default</emphasis>. The <emphasis>default</emphasis> mode will strip leading and\r
+        trailing empty lines and #commentary from the commit message\r
+        only if the message is to be edited. Otherwise only whitespace\r
+        removed. The <emphasis>verbatim</emphasis> mode does not change message at all,\r
+        <emphasis>whitespace</emphasis> removes just leading/trailing whitespace lines\r
+        and <emphasis>strip</emphasis> removes both whitespace and commentary.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-e\r
+</term>\r
+<term>\r
+--edit\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The message taken from file with <literal>-F</literal>, command line with\r
+        <literal>-m</literal>, and from file with <literal>-C</literal> are usually used as the\r
+        commit log message unmodified.  This option lets you\r
+        further edit the message taken from these sources.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--amend\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Used to amend the tip of the current branch. Prepare the tree\r
+        object you would want to replace the latest commit as usual\r
+        (this includes the usual -i/-o and explicit paths), and the\r
+        commit log editor is seeded with the commit message from the\r
+        tip of the current branch. The commit you create replaces the\r
+        current tip&#8201;&#8212;&#8201;if it was a merge, it will have the parents of\r
+        the current tip as parents&#8201;&#8212;&#8201;so the current top commit is\r
+        discarded.\r
+</simpara>\r
+<simpara>It is a rough equivalent for:</simpara>\r
+<literallayout>        $ git reset --soft HEAD^\r
+        $ ... do something else to come up with the right tree ...\r
+        $ git commit -c ORIG_HEAD</literallayout>\r
+<simpara>but can be used to amend a merge commit.</simpara>\r
+<simpara>You should understand the implications of rewriting history if you\r
+amend a commit that has already been published.  (See the "RECOVERING\r
+FROM UPSTREAM REBASE" section in <xref linkend="git-rebase(1)"/>.)</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-i\r
+</term>\r
+<term>\r
+--include\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Before making a commit out of staged contents so far,\r
+        stage the contents of paths given on the command line\r
+        as well.  This is usually not what you want unless you\r
+        are concluding a conflicted merge.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-o\r
+</term>\r
+<term>\r
+--only\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Make a commit only from the paths specified on the\r
+        command line, disregarding any contents that have been\r
+        staged so far. This is the default mode of operation of\r
+        <emphasis>git-commit</emphasis> if any paths are given on the command line,\r
+        in which case this option can be omitted.\r
+        If this option is specified together with <emphasis>--amend</emphasis>, then\r
+        no paths need to be specified, which can be used to amend\r
+        the last commit without committing changes that have\r
+        already been staged.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-u[&lt;mode&gt;]\r
+</term>\r
+<term>\r
+--untracked-files[=&lt;mode&gt;]\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show untracked files (Default: <emphasis>all</emphasis>).\r
+</simpara>\r
+<simpara>The mode parameter is optional, and is used to specify\r
+the handling of untracked files. The possible options are:</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+<emphasis>no</emphasis>     - Show no untracked files\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<emphasis>normal</emphasis> - Shows untracked files and directories\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<emphasis>all</emphasis>    - Also shows individual files in untracked directories.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simpara>See <xref linkend="git-config(1)"/> for configuration variable\r
+used to change the default for when the option is not\r
+specified.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-v\r
+</term>\r
+<term>\r
+--verbose\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Show unified diff between the HEAD commit and what\r
+        would be committed at the bottom of the commit message\r
+        template.  Note that this diff output doesn&#8217;t have its\r
+        lines prefixed with <emphasis>#</emphasis>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-q\r
+</term>\r
+<term>\r
+--quiet\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Suppress commit summary message.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Do not interpret any more arguments as options.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+&lt;file&gt;&#8230;\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        When files are given on the command line, the command\r
+        commits the contents of the named files, without\r
+        recording the changes already staged.  The contents of\r
+        these files are also staged for the next commit on top\r
+        of what have been staged before.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_examples">\r
+<title>EXAMPLES</title>\r
+<simpara>When recording your own work, the contents of modified files in\r
+your working tree are temporarily stored to a staging area\r
+called the "index" with <emphasis>git-add</emphasis>.  A file can be\r
+reverted back, only in the index but not in the working tree,\r
+to that of the last commit with <literal>git reset HEAD&#8201;&#8212;&#8201;&lt;file&gt;</literal>,\r
+which effectively reverts <emphasis>git-add</emphasis> and prevents the changes to\r
+this file from participating in the next commit.  After building\r
+the state to be committed incrementally with these commands,\r
+<literal>git commit</literal> (without any pathname parameter) is used to record what\r
+has been staged so far.  This is the most basic form of the\r
+command.  An example:</simpara>\r
+<literallayout>$ edit hello.c\r
+$ git rm goodbye.c\r
+$ git add hello.c\r
+$ git commit</literallayout>\r
+<simpara>Instead of staging files after each individual change, you can\r
+tell <literal>git commit</literal> to notice the changes to the files whose\r
+contents are tracked in\r
+your working tree and do corresponding <literal>git add</literal> and <literal>git rm</literal>\r
+for you.  That is, this example does the same as the earlier\r
+example if there is no other change in your working tree:</simpara>\r
+<literallayout>$ edit hello.c\r
+$ rm goodbye.c\r
+$ git commit -a</literallayout>\r
+<simpara>The command <literal>git commit -a</literal> first looks at your working tree,\r
+notices that you have modified hello.c and removed goodbye.c,\r
+and performs necessary <literal>git add</literal> and <literal>git rm</literal> for you.</simpara>\r
+<simpara>After staging changes to many files, you can alter the order the\r
+changes are recorded in, by giving pathnames to <literal>git commit</literal>.\r
+When pathnames are given, the command makes a commit that\r
+only records the changes made to the named paths:</simpara>\r
+<literallayout>$ edit hello.c hello.h\r
+$ git add hello.c hello.h\r
+$ edit Makefile\r
+$ git commit Makefile</literallayout>\r
+<simpara>This makes a commit that records the modification to <literal>Makefile</literal>.\r
+The changes staged for <literal>hello.c</literal> and <literal>hello.h</literal> are not included\r
+in the resulting commit.  However, their changes are not lost&#8201;&#8212;&#8201;they are still staged and merely held back.  After the above\r
+sequence, if you do:</simpara>\r
+<literallayout>$ git commit</literallayout>\r
+<simpara>this second commit would record the changes to <literal>hello.c</literal> and\r
+<literal>hello.h</literal> as expected.</simpara>\r
+<simpara>After a merge (initiated by <emphasis>git-merge</emphasis> or <emphasis>git-pull</emphasis>) stops\r
+because of conflicts, cleanly merged\r
+paths are already staged to be committed for you, and paths that\r
+conflicted are left in unmerged state.  You would have to first\r
+check which paths are conflicting with <emphasis>git-status</emphasis>\r
+and after fixing them manually in your working tree, you would\r
+stage the result as usual with <emphasis>git-add</emphasis>:</simpara>\r
+<literallayout>$ git status | grep unmerged\r
+unmerged: hello.c\r
+$ edit hello.c\r
+$ git add hello.c</literallayout>\r
+<simpara>After resolving conflicts and staging the result, <literal>git ls-files -u</literal>\r
+would stop mentioning the conflicted path.  When you are done,\r
+run <literal>git commit</literal> to finally record the merge:</simpara>\r
+<literallayout>$ git commit</literallayout>\r
+<simpara>As with the case to record your own changes, you can use <literal>-a</literal>\r
+option to save typing.  One difference is that during a merge\r
+resolution, you cannot use <literal>git commit</literal> with pathnames to\r
+alter the order the changes are committed, because the merge\r
+should be recorded as a single commit.  In fact, the command\r
+refuses to run when given pathnames (but see <literal>-i</literal> option).</simpara>\r
+</simplesect>\r
+<simplesect id="_discussion">\r
+<title>DISCUSSION</title>\r
+<simpara>Though not required, it&#8217;s a good idea to begin the commit message\r
+with a single short (less than 50 character) line summarizing the\r
+change, followed by a blank line and then a more thorough description.\r
+Tools that turn commits into email, for example, use the first line\r
+on the Subject: line and the rest of the commit in the body.</simpara>\r
+<simpara>At the core level, git is character encoding agnostic.</simpara>\r
+<itemizedlist>\r
+<listitem>\r
+<simpara>\r
+The pathnames recorded in the index and in the tree objects\r
+   are treated as uninterpreted sequences of non-NUL bytes.\r
+   What readdir(2) returns are what are recorded and compared\r
+   with the data git keeps track of, which in turn are expected\r
+   to be what lstat(2) and creat(2) accepts.  There is no such\r
+   thing as pathname encoding translation.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+The contents of the blob objects are uninterpreted sequences\r
+   of bytes.  There is no encoding translation at the core\r
+   level.\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+The commit log messages are uninterpreted sequences of non-NUL\r
+   bytes.\r
+</simpara>\r
+</listitem>\r
+</itemizedlist>\r
+<simpara>Although we encourage that the commit log messages are encoded\r
+in UTF-8, both the core and git Porcelain are designed not to\r
+force UTF-8 on projects.  If all participants of a particular\r
+project find it more convenient to use legacy encodings, git\r
+does not forbid it.  However, there are a few things to keep in\r
+mind.</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+<emphasis>git-commit</emphasis> and <emphasis>git-commit-tree</emphasis> issues\r
+  a warning if the commit log message given to it does not look\r
+  like a valid UTF-8 string, unless you explicitly say your\r
+  project uses a legacy encoding.  The way to say this is to\r
+  have i18n.commitencoding in <literal>.git/config</literal> file, like this:\r
+</simpara>\r
+<literallayout>[i18n]\r
+        commitencoding = ISO-8859-1</literallayout>\r
+<simpara>Commit objects created with the above setting record the value\r
+of <literal>i18n.commitencoding</literal> in its <literal>encoding</literal> header.  This is to\r
+help other people who look at them later.  Lack of this header\r
+implies that the commit log message is encoded in UTF-8.</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+<emphasis>git-log</emphasis>, <emphasis>git-show</emphasis>, <emphasis>git-blame</emphasis> and friends look at the\r
+  <literal>encoding</literal> header of a commit object, and try to re-code the\r
+  log message into UTF-8 unless otherwise specified.  You can\r
+  specify the desired output encoding with\r
+  <literal>i18n.logoutputencoding</literal> in <literal>.git/config</literal> file, like this:\r
+</simpara>\r
+<literallayout>[i18n]\r
+        logoutputencoding = ISO-8859-1</literallayout>\r
+<simpara>If you do not have this configuration variable, the value of\r
+<literal>i18n.commitencoding</literal> is used instead.</simpara>\r
+</listitem>\r
+</orderedlist>\r
+<simpara>Note that we deliberately chose not to re-code the commit log\r
+message when a commit is made to force UTF-8 at the commit\r
+object level, because re-coding to UTF-8 is not necessarily a\r
+reversible operation.</simpara>\r
+</simplesect>\r
+<simplesect id="_environment_and_configuration_variables">\r
+<title>ENVIRONMENT AND CONFIGURATION VARIABLES</title>\r
+<simpara>The editor used to edit the commit log message will be chosen from the\r
+GIT_EDITOR environment variable, the core.editor configuration variable, the\r
+VISUAL environment variable, or the EDITOR environment variable (in that\r
+order).</simpara>\r
+</simplesect>\r
+<simplesect id="_hooks">\r
+<title>HOOKS</title>\r
+<simpara>This command can run <literal>commit-msg</literal>, <literal>prepare-commit-msg</literal>, <literal>pre-commit</literal>,\r
+and <literal>post-commit</literal> hooks.  See <xref linkend="githooks(5)"/> for more\r
+information.</simpara>\r
+</simplesect>\r
+<simplesect id="_see_also">\r
+<title>SEE ALSO</title>\r
+<simpara><xref linkend="git-add(1)"/>,\r
+<xref linkend="git-rm(1)"/>,\r
+<xref linkend="git-mv(1)"/>,\r
+<xref linkend="git-merge(1)"/>,\r
+<xref linkend="git-commit-tree(1)"/></simpara>\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; and\r
+Junio C Hamano &lt;<ulink url="mailto:gitster@pobox.com">gitster@pobox.com</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
diff --git a/doc/source/en/TortoiseGit/git_doc/git-config.html.xml b/doc/source/en/TortoiseGit/git_doc/git-config.html.xml
new file mode 100644 (file)
index 0000000..5b62feb
--- /dev/null
@@ -0,0 +1,3169 @@
+<?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-config(1)">\r
+<articleinfo>\r
+    <title>git-config(1)</title>\r
+        <indexterm>\r
+                <primary>git-config(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-config - Get and set repository or global options</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<blockquote>\r
+<literallayout><emphasis>git config</emphasis> [&lt;file-option&gt;] [type] [-z|--null] name [value [value_regex]]\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] [type] --add name value\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] [type] --replace-all name [value [value_regex]]\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] [type] [-z|--null] --get name [value_regex]\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] [type] [-z|--null] --get-all name [value_regex]\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] [type] [-z|--null] --get-regexp name_regex [value_regex]\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] --unset name [value_regex]\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] --unset-all name [value_regex]\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] --rename-section old_name new_name\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] --remove-section name\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] [-z|--null] -l | --list\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] --get-color name [default]\r
+<emphasis>git config</emphasis> [&lt;file-option&gt;] --get-colorbool name [stdout-is-tty]</literallayout>\r
+</blockquote>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara>You can query/set/replace/unset options with this command. The name is\r
+actually the section and the key separated by a dot, and the value will be\r
+escaped.</simpara>\r
+<simpara>Multiple lines can be added to an option by using the <emphasis>--add</emphasis> option.\r
+If you want to update or unset an option which can occur on multiple\r
+lines, a POSIX regexp <literal>value_regex</literal> needs to be given.  Only the\r
+existing values that match the regexp are updated or unset.  If\r
+you want to handle the lines that do <emphasis role="strong">not</emphasis> match the regex, just\r
+prepend a single exclamation mark in front (see also <xref linkend="EXAMPLES"/>).</simpara>\r
+<simpara>The type specifier can be either <emphasis>--int</emphasis> or <emphasis>--bool</emphasis>, which will make\r
+<emphasis>git-config</emphasis> ensure that the variable(s) are of the given type and\r
+convert the value to the canonical form (simple decimal number for int,\r
+a "true" or "false" string for bool).  If no type specifier is passed,\r
+no checks or transformations are performed on the value.</simpara>\r
+<simpara>The file-option can be one of <emphasis>--system</emphasis>, <emphasis>--global</emphasis> or <emphasis>--file</emphasis>\r
+which specify where the values will be read from or written to.\r
+The default is to assume the config file of the current repository,\r
+.git/config unless defined otherwise with GIT_DIR and GIT_CONFIG\r
+(see <xref linkend="FILES"/>).</simpara>\r
+<simpara>This command will fail if:</simpara>\r
+<orderedlist numeration="arabic">\r
+<listitem>\r
+<simpara>\r
+The config file is invalid,\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+Can not write to the config file,\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+no section was provided,\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+the section or key is invalid,\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+you try to unset an option which does not exist,\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+you try to unset/set an option for which multiple lines match, or\r
+</simpara>\r
+</listitem>\r
+<listitem>\r
+<simpara>\r
+you use <emphasis>--global</emphasis> option without $HOME being properly set.\r
+</simpara>\r
+</listitem>\r
+</orderedlist>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+--replace-all\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Default behavior is to replace at most one line. This replaces\r
+        all lines matching the key (and optionally the value_regex).\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--add\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Adds a new line to the option without altering any existing\r
+        values.  This is the same as providing <emphasis>^$</emphasis> as the value_regex.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--get\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Get the value for a given key (optionally filtered by a regex\r
+        matching the value). Returns error code 1 if the key was not\r
+        found and error code 2 if multiple key values were found.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--get-all\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Like get, but does not fail if the number of values for the key\r
+        is not exactly one.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--get-regexp\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Like --get-all, but interprets the name as a regular expression.\r
+        Also outputs the key names.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--global\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        For writing options: write to global ~/.gitconfig file rather than\r
+        the repository .git/config.\r
+</simpara>\r
+<simpara>For reading options: read only from global ~/.gitconfig rather than\r
+from all available files.</simpara>\r
+<simpara>See also <xref linkend="FILES"/>.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--system\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        For writing options: write to system-wide $(prefix)/etc/gitconfig\r
+        rather than the repository .git/config.\r
+</simpara>\r
+<simpara>For reading options: read only from system-wide $(prefix)/etc/gitconfig\r
+rather than from all available files.</simpara>\r
+<simpara>See also <xref linkend="FILES"/>.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-f config-file\r
+</term>\r
+<term>\r
+--file config-file\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Use the given config file instead of the one specified by GIT_CONFIG.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--remove-section\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Remove the given section from the configuration file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--rename-section\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Rename the given section to a new name.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--unset\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Remove the line matching the key from config file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--unset-all\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Remove all lines matching the key from config file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-l\r
+</term>\r
+<term>\r
+--list\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        List all variables set in config file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--bool\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        <emphasis>git-config</emphasis> will ensure that the output is "true" or "false"\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--int\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        <emphasis>git-config</emphasis> will ensure that the output is a simple\r
+        decimal number.  An optional value suffix of <emphasis>k</emphasis>, <emphasis>m</emphasis>, or <emphasis>g</emphasis>\r
+        in the config file will cause the value to be multiplied\r
+        by 1024, 1048576, or 1073741824 prior to output.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+-z\r
+</term>\r
+<term>\r
+--null\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        For all options that output values and/or keys, always\r
+        end values with the null character (instead of a\r
+        newline). Use newline instead as a delimiter between\r
+        key and value. This allows for secure parsing of the\r
+        output without getting confused e.g. by values that\r
+        contain line breaks.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--get-colorbool name [stdout-is-tty]\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Find the color setting for <literal>name</literal> (e.g. <literal>color.diff</literal>) and output\r
+        "true" or "false".  <literal>stdout-is-tty</literal> should be either "true" or\r
+        "false", and is taken into account when configuration says\r
+        "auto".  If <literal>stdout-is-tty</literal> is missing, then checks the standard\r
+        output of the command itself, and exits with status 0 if color\r
+        is to be used, or exits with status 1 otherwise.\r
+        When the color setting for <literal>name</literal> is undefined, the command uses\r
+        <literal>color.ui</literal> as fallback.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+--get-color name default\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Find the color configured for <literal>name</literal> (e.g. <literal>color.diff.new</literal>) and\r
+        output it as the ANSI color escape sequence to the standard\r
+        output.  The optional <literal>default</literal> parameter is used instead, if\r
+        there is no color configured for <literal>name</literal>.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="FILES">\r
+<title>FILES</title>\r
+<simpara>If not set explicitly with <emphasis>--file</emphasis>, there are three files where\r
+<emphasis>git-config</emphasis> will search for configuration options:</simpara>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+$GIT_DIR/config\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Repository specific configuration file. (The filename is\r
+        of course relative to the repository root, not the working\r
+        directory.)\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+~/.gitconfig\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        User-specific configuration file. Also called "global"\r
+        configuration file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+$(prefix)/etc/gitconfig\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        System-wide configuration file.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+<simpara>If no further options are given, all reading options will read all of these\r
+files that are available. If the global or the system-wide configuration\r
+file are not available they will be ignored. If the repository configuration\r
+file is not available or readable, <emphasis>git-config</emphasis> will exit with a non-zero\r
+error code. However, in neither case will an error message be issued.</simpara>\r
+<simpara>All writing options will per default write to the repository specific\r
+configuration file. Note that this also affects options like <emphasis>--replace-all</emphasis>\r
+and <emphasis>--unset</emphasis>. <emphasis role="strong"><emphasis>git-config</emphasis> will only ever change one file at a time</emphasis>.</simpara>\r
+<simpara>You can override these rules either by command line options or by environment\r
+variables. The <emphasis>--global</emphasis> and the <emphasis>--system</emphasis> options will limit the file used\r
+to the global or system-wide file respectively. The GIT_CONFIG environment\r
+variable has a similar effect, but you can specify any filename you want.</simpara>\r
+</simplesect>\r
+<simplesect id="_environment">\r
+<title>ENVIRONMENT</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+GIT_CONFIG\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Take the configuration from the given file instead of .git/config.\r
+        Using the "--global" option forces this to ~/.gitconfig. Using the\r
+        "--system" option forces this to $(prefix)/etc/gitconfig.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+<simpara>See also <xref linkend="FILES"/>.</simpara>\r
+</simplesect>\r
+<simplesect id="EXAMPLES">\r
+<title>EXAMPLES</title>\r
+<simpara>Given a .git/config like this:</simpara>\r
+<literallayout class="monospaced">#\r
+# This is the config file, and\r
+# a '#' or ';' character indicates\r
+# a comment\r
+#</literallayout>\r
+<literallayout class="monospaced">; core variables\r
+[core]\r
+        ; Don't trust file modes\r
+        filemode = false</literallayout>\r
+<literallayout class="monospaced">; Our diff algorithm\r
+[diff]\r
+        external = /usr/local/bin/diff-wrapper\r
+        renames = true</literallayout>\r
+<literallayout class="monospaced">; Proxy settings\r
+[core]\r
+        gitproxy="proxy-command" for kernel.org\r
+        gitproxy=default-proxy ; for all the rest</literallayout>\r
+<simpara>you can set the filemode to true with</simpara>\r
+<literallayout>% git config core.filemode true</literallayout>\r
+<simpara>The hypothetical proxy command entries actually have a postfix to discern\r
+what URL they apply to. Here is how to change the entry for kernel.org\r
+to "ssh".</simpara>\r
+<literallayout>% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'</literallayout>\r
+<simpara>This makes sure that only the key/value pair for kernel.org is replaced.</simpara>\r
+<simpara>To delete the entry for renames, do</simpara>\r
+<literallayout>% git config --unset diff.renames</literallayout>\r
+<simpara>If you want to delete an entry for a multivar (like core.gitproxy above),\r
+you have to provide a regex matching the value of exactly one line.</simpara>\r
+<simpara>To query the value for a given key, do</simpara>\r
+<literallayout>% git config --get core.filemode</literallayout>\r
+<simpara>or</simpara>\r
+<literallayout>% git config core.filemode</literallayout>\r
+<simpara>or, to query a multivar:</simpara>\r
+<literallayout>% git config --get core.gitproxy "for kernel.org$"</literallayout>\r
+<simpara>If you want to know all the values for a multivar, do:</simpara>\r
+<literallayout>% git config --get-all core.gitproxy</literallayout>\r
+<simpara>If you like to live dangerously, you can replace <emphasis role="strong">all</emphasis> core.gitproxy by a\r
+new one with</simpara>\r
+<literallayout>% git config --replace-all core.gitproxy ssh</literallayout>\r
+<simpara>However, if you really only want to replace the line for the default proxy,\r
+i.e. the one without a "for &#8230;" postfix, do something like this:</simpara>\r
+<literallayout>% git config core.gitproxy ssh '! for '</literallayout>\r
+<simpara>To actually match only values with an exclamation mark, you have to</simpara>\r
+<literallayout>% git config section.key value '[!]'</literallayout>\r
+<simpara>To add a new proxy, without altering any of the existing ones, use</simpara>\r
+<literallayout>% git config core.gitproxy '"proxy-command" for example.com'</literallayout>\r
+<simpara>An example to use customized color from the configuration in your\r
+script:</simpara>\r
+<literallayout>#!/bin/sh\r
+WS=$(git config --get-color color.diff.whitespace "blue reverse")\r
+RESET=$(git config --get-color "" "reset")\r
+echo "${WS}your whitespace color or blue reverse${RESET}"</literallayout>\r
+</simplesect>\r
+<simplesect id="_configuration_file">\r
+<title>CONFIGURATION FILE</title>\r
+<simpara>The git configuration file contains a number of variables that affect\r
+the git command&#8217;s behavior. <literal>.git/config</literal> file for each repository\r
+is used to store the information for that repository, and\r
+<literal>$HOME/.gitconfig</literal> is used to store per user information to give\r
+fallback values for <literal>.git/config</literal> file. The file <literal>/etc/gitconfig</literal>\r
+can be used to store system-wide defaults.</simpara>\r
+<simpara>They can be used by both the git plumbing\r
+and the porcelains. The variables are divided into sections, where\r
+in the fully qualified variable name the variable itself is the last\r
+dot-separated segment and the section name is everything before the last\r
+dot. The variable names are case-insensitive and only alphanumeric\r
+characters are allowed. Some variables may appear multiple times.</simpara>\r
+<simplesect id="_syntax">\r
+<title>Syntax</title>\r
+<simpara>The syntax is fairly flexible and permissive; whitespaces are mostly\r
+ignored.  The <emphasis>#</emphasis> and <emphasis>;</emphasis> characters begin comments to the end of line,\r
+blank lines are ignored.</simpara>\r
+<simpara>The file consists of sections and variables.  A section begins with\r
+the name of the section in square brackets and continues until the next\r
+section begins.  Section names are not case sensitive.  Only alphanumeric\r
+characters, <emphasis><literal>-</literal></emphasis> and <emphasis><literal>.</literal></emphasis> are allowed in section names.  Each variable\r
+must belong to some section, which means that there must be section\r
+header before first setting of a variable.</simpara>\r
+<simpara>Sections can be further divided into subsections.  To begin a subsection\r
+put its name in double quotes, separated by space from the section name,\r
+in the section header, like in example below:</simpara>\r
+<literallayout>        [section "subsection"]</literallayout>\r
+<simpara>Subsection names can contain any characters except newline (doublequote\r
+<emphasis><literal>"</literal></emphasis> and backslash have to be escaped as <emphasis><literal>\"</literal></emphasis> and <emphasis><literal>\\</literal></emphasis>,\r
+respectively) and are case sensitive.  Section header cannot span multiple\r
+lines.  Variables may belong directly to a section or to a given subsection.\r
+You can have <literal>[section]</literal> if you have <literal>[section "subsection"]</literal>, but you\r
+don&#8217;t need to.</simpara>\r
+<simpara>There is also (case insensitive) alternative <literal>[section.subsection]</literal> syntax.\r
+In this syntax subsection names follow the same restrictions as for section\r
+name.</simpara>\r
+<simpara>All the other lines are recognized as setting variables, in the form\r
+<emphasis>name = value</emphasis>.  If there is no equal sign on the line, the entire line\r
+is taken as <emphasis>name</emphasis> and the variable is recognized as boolean "true".\r
+The variable names are case-insensitive and only alphanumeric\r
+characters and <emphasis><literal>-</literal></emphasis> are allowed.  There can be more than one value\r
+for a given variable; we say then that variable is multivalued.</simpara>\r
+<simpara>Leading and trailing whitespace in a variable value is discarded.\r
+Internal whitespace within a variable value is retained verbatim.</simpara>\r
+<simpara>The values following the equals sign in variable assign are all either\r
+a string, an integer, or a boolean.  Boolean values may be given as yes/no,\r
+0/1 or true/false.  Case is not significant in boolean values, when\r
+converting value to the canonical form using <emphasis>--bool</emphasis> type specifier;\r
+<emphasis>git-config</emphasis> will ensure that the output is "true" or "false".</simpara>\r
+<simpara>String values may be entirely or partially enclosed in double quotes.\r
+You need to enclose variable value in double quotes if you want to\r
+preserve leading or trailing whitespace, or if variable value contains\r
+beginning of comment characters (if it contains <emphasis>#</emphasis> or <emphasis>;</emphasis>).\r
+Double quote <emphasis><literal>"</literal></emphasis> and backslash <emphasis><literal>\</literal></emphasis> characters in variable value must\r
+be escaped: use <emphasis><literal>\"</literal></emphasis> for <emphasis><literal>"</literal></emphasis> and <emphasis><literal>\\</literal></emphasis> for <emphasis><literal>\</literal></emphasis>.</simpara>\r
+<simpara>The following escape sequences (beside <emphasis><literal>\"</literal></emphasis> and <emphasis><literal>\\</literal></emphasis>) are recognized:\r
+<emphasis><literal>\n</literal></emphasis> for newline character (NL), <emphasis><literal>\t</literal></emphasis> for horizontal tabulation (HT, TAB)\r
+and <emphasis><literal>\b</literal></emphasis> for backspace (BS).  No other char escape sequence, nor octal\r
+char sequences are valid.</simpara>\r
+<simpara>Variable value ending in a <emphasis><literal>\</literal></emphasis> is continued on the next line in the\r
+customary UNIX fashion.</simpara>\r
+<simpara>Some variables may require special value format.</simpara>\r
+</simplesect>\r
+<simplesect id="_example">\r
+<title>Example</title>\r
+<literallayout class="monospaced"># Core variables\r
+[core]\r
+        ; Don't trust file modes\r
+        filemode = false</literallayout>\r
+<literallayout class="monospaced"># Our diff algorithm\r
+[diff]\r
+        external = /usr/local/bin/diff-wrapper\r
+        renames = true</literallayout>\r
+<literallayout class="monospaced">[branch "devel"]\r
+        remote = origin\r
+        merge = refs/heads/devel</literallayout>\r
+<literallayout class="monospaced"># Proxy settings\r
+[core]\r
+        gitProxy="ssh" for "kernel.org"\r
+        gitProxy=default-proxy ; for the rest</literallayout>\r
+</simplesect>\r
+<simplesect id="_variables">\r
+<title>Variables</title>\r
+<simpara>Note that this list is non-comprehensive and not necessarily complete.\r
+For command-specific variables, you will find a more detailed description\r
+in the appropriate manual page. You will find a description of non-core\r
+porcelain configuration variables in the respective porcelain documentation.</simpara>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+core.fileMode\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If false, the executable bit differences between the index and\r
+        the working copy are ignored; useful on broken filesystems like FAT.\r
+        See <xref linkend="git-update-index(1)"/>. True by default.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.ignoreCygwinFSTricks\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        This option is only used by Cygwin implementation of Git. If false,\r
+        the Cygwin stat() and lstat() functions are used. This may be useful\r
+        if your repository consists of a few separate directories joined in\r
+        one hierarchy using Cygwin mount. If true, Git uses native Win32 API\r
+        whenever it is possible and falls back to Cygwin functions only to\r
+        handle symbol links. The native mode is more than twice faster than\r
+        normal Cygwin l/stat() functions. True by default, unless core.filemode\r
+        is true, in which case ignoreCygwinFSTricks is ignored as Cygwin&#8217;s\r
+        POSIX emulation is required to support core.filemode.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.trustctime\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If false, the ctime differences between the index and the\r
+        working copy are ignored; useful when the inode change time\r
+        is regularly modified by something outside Git (file system\r
+        crawlers and some backup systems).\r
+        See <xref linkend="git-update-index(1)"/>. True by default.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.quotepath\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        The commands that output paths (e.g. <emphasis>ls-files</emphasis>,\r
+        <emphasis>diff</emphasis>), when not given the <literal>-z</literal> option, will quote\r
+        "unusual" characters in the pathname by enclosing the\r
+        pathname in a double-quote pair and with backslashes the\r
+        same way strings in C source code are quoted.  If this\r
+        variable is set to false, the bytes higher than 0x80 are\r
+        not quoted but output as verbatim.  Note that double\r
+        quote, backslash and control characters are always\r
+        quoted without <literal>-z</literal> regardless of the setting of this\r
+        variable.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.autocrlf\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If true, makes git convert <literal>CRLF</literal> at the end of lines in text files to\r
+        <literal>LF</literal> when reading from the filesystem, and convert in reverse when\r
+        writing to the filesystem.  The variable can be set to\r
+        <emphasis>input</emphasis>, in which case the conversion happens only while\r
+        reading from the filesystem but files are written out with\r
+        <literal>LF</literal> at the end of lines.  Currently, which paths to consider\r
+        "text" (i.e. be subjected to the autocrlf mechanism) is\r
+        decided purely based on the contents.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.safecrlf\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If true, makes git check if converting <literal>CRLF</literal> as controlled by\r
+        <literal>core.autocrlf</literal> is reversible.  Git will verify if a command\r
+        modifies a file in the work tree either directly or indirectly.\r
+        For example, committing a file followed by checking out the\r
+        same file should yield the original file in the work tree.  If\r
+        this is not the case for the current setting of\r
+        <literal>core.autocrlf</literal>, git will reject the file.  The variable can\r
+        be set to "warn", in which case git will only warn about an\r
+        irreversible conversion but continue the operation.\r
+</simpara>\r
+<simpara>CRLF conversion bears a slight chance of corrupting data.\r
+autocrlf=true will convert CRLF to LF during commit and LF to\r
+CRLF during checkout.  A file that contains a mixture of LF and\r
+CRLF before the commit cannot be recreated by git.  For text\r
+files this is the right thing to do: it corrects line endings\r
+such that we have only LF line endings in the repository.\r
+But for binary files that are accidentally classified as text the\r
+conversion can corrupt data.</simpara>\r
+<simpara>If you recognize such corruption early you can easily fix it by\r
+setting the conversion type explicitly in .gitattributes.  Right\r
+after committing you still have the original file in your work\r
+tree and this file is not yet corrupted.  You can explicitly tell\r
+git that this file is binary and git will handle the file\r
+appropriately.</simpara>\r
+<simpara>Unfortunately, the desired effect of cleaning up text files with\r
+mixed line endings and the undesired effect of corrupting binary\r
+files cannot be distinguished.  In both cases CRLFs are removed\r
+in an irreversible way.  For text files this is the right thing\r
+to do because CRLFs are line endings, while for binary files\r
+converting CRLFs corrupts data.</simpara>\r
+<simpara>Note, this safety check does not mean that a checkout will generate a\r
+file identical to the original file for a different setting of\r
+<literal>core.autocrlf</literal>, but only for the current one.  For example, a text\r
+file with <literal>LF</literal> would be accepted with <literal>core.autocrlf=input</literal> and could\r
+later be checked out with <literal>core.autocrlf=true</literal>, in which case the\r
+resulting file would contain <literal>CRLF</literal>, although the original file\r
+contained <literal>LF</literal>.  However, in both work trees the line endings would be\r
+consistent, that is either all <literal>LF</literal> or all <literal>CRLF</literal>, but never mixed.  A\r
+file with mixed line endings would be reported by the <literal>core.safecrlf</literal>\r
+mechanism.</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.symlinks\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If false, symbolic links are checked out as small plain files that\r
+        contain the link text. <xref linkend="git-update-index(1)"/> and\r
+        <xref linkend="git-add(1)"/> will not change the recorded type to regular\r
+        file. Useful on filesystems like FAT that do not support\r
+        symbolic links. True by default.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.gitProxy\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        A "proxy command" to execute (as <emphasis>command host port</emphasis>) instead\r
+        of establishing direct connection to the remote server when\r
+        using the git protocol for fetching. If the variable value is\r
+        in the "COMMAND for DOMAIN" format, the command is applied only\r
+        on hostnames ending with the specified domain string. This variable\r
+        may be set multiple times and is matched in the given order;\r
+        the first match wins.\r
+</simpara>\r
+<simpara>Can be overridden by the <emphasis>GIT_PROXY_COMMAND</emphasis> environment variable\r
+(which always applies universally, without the special "for"\r
+handling).</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.ignoreStat\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        If true, commands which modify both the working tree and the index\r
+        will mark the updated paths with the "assume unchanged" bit in the\r
+        index. These marked files are then assumed to stay unchanged in the\r
+        working copy, until you mark them otherwise manually - Git will not\r
+        detect the file changes by lstat() calls. This is useful on systems\r
+        where those are very slow, such as Microsoft Windows.\r
+        See <xref linkend="git-update-index(1)"/>.\r
+        False by default.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+<varlistentry>\r
+<term>\r
+core.preferSymlinkRefs\r
+</term>\r
+<listitem>\r
+<simpara>