OSDN Git Service

Add Git official document to help
[tortoisegit/TortoiseGitJp.git] / doc / source / en / TortoiseGit / git_doc / git-merge-base.html.xml
diff --git a/doc/source/en/TortoiseGit/git_doc/git-merge-base.html.xml b/doc/source/en/TortoiseGit/git_doc/git-merge-base.html.xml
new file mode 100644 (file)
index 0000000..cbb87df
--- /dev/null
@@ -0,0 +1,99 @@
+<?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-merge-base(1)">\r
+<articleinfo>\r
+    <title>git-merge-base(1)</title>\r
+        <indexterm>\r
+                <primary>git-merge-base(1)</primary>\r
+        </indexterm>\r
+</articleinfo>\r
+<simplesect id="_name">\r
+<title>NAME</title>\r
+<simpara>git-merge-base - Find as good common ancestors as possible for a merge</simpara>\r
+</simplesect>\r
+<simplesect id="_synopsis">\r
+<title>SYNOPSIS</title>\r
+<simpara><emphasis>git merge-base</emphasis> [--all] &lt;commit&gt; &lt;commit&gt;&#8230;</simpara>\r
+</simplesect>\r
+<simplesect id="_description">\r
+<title>DESCRIPTION</title>\r
+<simpara><emphasis>git-merge-base</emphasis> finds best common ancestor(s) between two commits to use\r
+in a three-way merge.  One common ancestor is <emphasis>better</emphasis> than another common\r
+ancestor if the latter is an ancestor of the former.  A common ancestor\r
+that does not have any better common ancestor is a <emphasis>best common\r
+ancestor</emphasis>, i.e. a <emphasis>merge base</emphasis>.  Note that there can be more than one\r
+merge base for a pair of commits.</simpara>\r
+<simpara>Among the two commits to compute the merge base from, one is specified by\r
+the first commit argument on the command line; the other commit is a\r
+(possibly hypothetical) commit that is a merge across all the remaining\r
+commits on the command line.  As the most common special case, specifying only\r
+two commits on the command line means computing the merge base between\r
+the given two commits.</simpara>\r
+</simplesect>\r
+<simplesect id="_options">\r
+<title>OPTIONS</title>\r
+<variablelist>\r
+<varlistentry>\r
+<term>\r
+--all\r
+</term>\r
+<listitem>\r
+<simpara>\r
+        Output all merge bases for the commits, instead of just one.\r
+</simpara>\r
+</listitem>\r
+</varlistentry>\r
+</variablelist>\r
+</simplesect>\r
+<simplesect id="_discussion">\r
+<title>DISCUSSION</title>\r
+<simpara>Given two commits <emphasis>A</emphasis> and <emphasis>B</emphasis>, <literal>git merge-base A B</literal> will output a commit\r
+which is reachable from both <emphasis>A</emphasis> and <emphasis>B</emphasis> through the parent relationship.</simpara>\r
+<simpara>For example, with this topology:</simpara>\r
+<literallayout class="monospaced">         o---o---o---B\r
+        /\r
+---o---1---o---o---o---A</literallayout>\r
+<simpara>the merge base between <emphasis>A</emphasis> and <emphasis>B</emphasis> is <emphasis>1</emphasis>.</simpara>\r
+<simpara>Given three commits <emphasis>A</emphasis>, <emphasis>B</emphasis> and <emphasis>C</emphasis>, <literal>git merge-base A B C</literal> will compute the\r
+merge base between <emphasis>A</emphasis> and a hypothetical commit <emphasis>M</emphasis>, which is a merge\r
+between <emphasis>B</emphasis> and <emphasis>C</emphasis>.  For example, with this topology:</simpara>\r
+<literallayout class="monospaced">       o---o---o---o---C\r
+      /\r
+     /   o---o---o---B\r
+    /   /\r
+---2---1---o---o---o---A</literallayout>\r
+<simpara>the result of <literal>git merge-base A B C</literal> is <emphasis>1</emphasis>.  This is because the\r
+equivalent topology with a merge commit <emphasis>M</emphasis> between <emphasis>B</emphasis> and <emphasis>C</emphasis> is:</simpara>\r
+<literallayout class="monospaced">       o---o---o---o---o\r
+      /                 \\r
+     /   o---o---o---o---M\r
+    /   /\r
+---2---1---o---o---o---A</literallayout>\r
+<simpara>and the result of <literal>git merge-base A M</literal> is <emphasis>1</emphasis>.  Commit <emphasis>2</emphasis> is also a\r
+common ancestor between <emphasis>A</emphasis> and <emphasis>M</emphasis>, but <emphasis>1</emphasis> is a better common ancestor,\r
+because <emphasis>2</emphasis> is an ancestor of <emphasis>1</emphasis>.  Hence, <emphasis>2</emphasis> is not a merge base.</simpara>\r
+<simpara>When the history involves criss-cross merges, there can be more than one\r
+<emphasis>best</emphasis> common ancestor for two commits.  For example, with this topology:</simpara>\r
+<literallayout class="monospaced">---1---o---A\r
+    \ /\r
+     X\r
+    / \\r
+---2---o---o---B</literallayout>\r
+<simpara>both <emphasis>1</emphasis> and <emphasis>2</emphasis> are merge-bases of A and B.  Neither one is better than\r
+the other (both are <emphasis>best</emphasis> merge bases).  When the <literal>--all</literal> option is not given,\r
+it is unspecified which best one is output.</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