about summary refs log tree commit diff
path: root/third_party/git/Documentation/git-merge-base.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/git/Documentation/git-merge-base.txt')
-rw-r--r--third_party/git/Documentation/git-merge-base.txt247
1 files changed, 0 insertions, 247 deletions
diff --git a/third_party/git/Documentation/git-merge-base.txt b/third_party/git/Documentation/git-merge-base.txt
deleted file mode 100644
index 2d944e0851f6..000000000000
--- a/third_party/git/Documentation/git-merge-base.txt
+++ /dev/null
@@ -1,247 +0,0 @@
-git-merge-base(1)
-=================
-
-NAME
-----
-git-merge-base - Find as good common ancestors as possible for a merge
-
-
-SYNOPSIS
---------
-[verse]
-'git merge-base' [-a|--all] <commit> <commit>...
-'git merge-base' [-a|--all] --octopus <commit>...
-'git merge-base' --is-ancestor <commit> <commit>
-'git merge-base' --independent <commit>...
-'git merge-base' --fork-point <ref> [<commit>]
-
-DESCRIPTION
------------
-
-'git merge-base' finds best common ancestor(s) between two commits to use
-in a three-way merge.  One common ancestor is 'better' than another common
-ancestor if the latter is an ancestor of the former.  A common ancestor
-that does not have any better common ancestor is a 'best common
-ancestor', i.e. a 'merge base'.  Note that there can be more than one
-merge base for a pair of commits.
-
-OPERATION MODES
----------------
-
-As the most common special case, specifying only two commits on the
-command line means computing the merge base between the given two commits.
-
-More generally, among the two commits to compute the merge base from,
-one is specified by the first commit argument on the command line;
-the other commit is a (possibly hypothetical) commit that is a merge
-across all the remaining commits on the command line.
-
-As a consequence, the 'merge base' is not necessarily contained in each of the
-commit arguments if more than two commits are specified. This is different
-from linkgit:git-show-branch[1] when used with the `--merge-base` option.
-
---octopus::
-	Compute the best common ancestors of all supplied commits,
-	in preparation for an n-way merge.  This mimics the behavior
-	of 'git show-branch --merge-base'.
-
---independent::
-	Instead of printing merge bases, print a minimal subset of
-	the supplied commits with the same ancestors.  In other words,
-	among the commits given, list those which cannot be reached
-	from any other.  This mimics the behavior of 'git show-branch
-	--independent'.
-
---is-ancestor::
-	Check if the first <commit> is an ancestor of the second <commit>,
-	and exit with status 0 if true, or with status 1 if not.
-	Errors are signaled by a non-zero status that is not 1.
-
---fork-point::
-	Find the point at which a branch (or any history that leads
-	to <commit>) forked from another branch (or any reference)
-	<ref>. This does not just look for the common ancestor of
-	the two commits, but also takes into account the reflog of
-	<ref> to see if the history leading to <commit> forked from
-	an earlier incarnation of the branch <ref> (see discussion
-	on this mode below).
-
-OPTIONS
--------
--a::
---all::
-	Output all merge bases for the commits, instead of just one.
-
-DISCUSSION
-----------
-
-Given two commits 'A' and 'B', `git merge-base A B` will output a commit
-which is reachable from both 'A' and 'B' through the parent relationship.
-
-For example, with this topology:
-
-....
-	 o---o---o---B
-	/
----o---1---o---o---o---A
-....
-
-the merge base between 'A' and 'B' is '1'.
-
-Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the
-merge base between 'A' and a hypothetical commit 'M', which is a merge
-between 'B' and 'C'.  For example, with this topology:
-
-....
-       o---o---o---o---C
-      /
-     /   o---o---o---B
-    /   /
----2---1---o---o---o---A
-....
-
-the result of `git merge-base A B C` is '1'.  This is because the
-equivalent topology with a merge commit 'M' between 'B' and 'C' is:
-
-
-....
-       o---o---o---o---o
-      /                 \
-     /   o---o---o---o---M
-    /   /
----2---1---o---o---o---A
-....
-
-and the result of `git merge-base A M` is '1'.  Commit '2' is also a
-common ancestor between 'A' and 'M', but '1' is a better common ancestor,
-because '2' is an ancestor of '1'.  Hence, '2' is not a merge base.
-
-The result of `git merge-base --octopus A B C` is '2', because '2' is
-the best common ancestor of all commits.
-
-When the history involves criss-cross merges, there can be more than one
-'best' common ancestor for two commits.  For example, with this topology:
-
-....
----1---o---A
-    \ /
-     X
-    / \
----2---o---o---B
-....
-
-both '1' and '2' are merge-bases of A and B.  Neither one is better than
-the other (both are 'best' merge bases).  When the `--all` option is not given,
-it is unspecified which best one is output.
-
-A common idiom to check "fast-forward-ness" between two commits A
-and B is (or at least used to be) to compute the merge base between
-A and B, and check if it is the same as A, in which case, A is an
-ancestor of B.  You will see this idiom used often in older scripts.
-
-....
-A=$(git rev-parse --verify A)
-if test "$A" = "$(git merge-base A B)"
-then
-	... A is an ancestor of B ...
-fi
-....
-
-In modern git, you can say this in a more direct way:
-
-....
-if git merge-base --is-ancestor A B
-then
-	... A is an ancestor of B ...
-fi
-....
-
-instead.
-
-Discussion on fork-point mode
------------------------------
-
-After working on the `topic` branch created with `git switch -c
-topic origin/master`, the history of remote-tracking branch
-`origin/master` may have been rewound and rebuilt, leading to a
-history of this shape:
-
-....
-		 o---B2
-		/
----o---o---B1--o---o---o---B (origin/master)
-	\
-	 B0
-	  \
-	   D0---D1---D (topic)
-....
-
-where `origin/master` used to point at commits B0, B1, B2 and now it
-points at B, and your `topic` branch was started on top of it back
-when `origin/master` was at B0, and you built three commits, D0, D1,
-and D, on top of it.  Imagine that you now want to rebase the work
-you did on the topic on top of the updated origin/master.
-
-In such a case, `git merge-base origin/master topic` would return the
-parent of B0 in the above picture, but B0^..D is *not* the range of
-commits you would want to replay on top of B (it includes B0, which
-is not what you wrote; it is a commit the other side discarded when
-it moved its tip from B0 to B1).
-
-`git merge-base --fork-point origin/master topic` is designed to
-help in such a case.  It takes not only B but also B0, B1, and B2
-(i.e. old tips of the remote-tracking branches your repository's
-reflog knows about) into account to see on which commit your topic
-branch was built and finds B0, allowing you to replay only the
-commits on your topic, excluding the commits the other side later
-discarded.
-
-Hence
-
-    $ fork_point=$(git merge-base --fork-point origin/master topic)
-
-will find B0, and
-
-    $ git rebase --onto origin/master $fork_point topic
-
-will replay D0, D1 and D on top of B to create a new history of this
-shape:
-
-....
-		 o---B2
-		/
----o---o---B1--o---o---o---B (origin/master)
-	\                   \
-	 B0                  D0'--D1'--D' (topic - updated)
-	  \
-	   D0---D1---D (topic - old)
-....
-
-A caveat is that older reflog entries in your repository may be
-expired by `git gc`.  If B0 no longer appears in the reflog of the
-remote-tracking branch `origin/master`, the `--fork-point` mode
-obviously cannot find it and fails, avoiding to give a random and
-useless result (such as the parent of B0, like the same command
-without the `--fork-point` option gives).
-
-Also, the remote-tracking branch you use the `--fork-point` mode
-with must be the one your topic forked from its tip.  If you forked
-from an older commit than the tip, this mode would not find the fork
-point (imagine in the above sample history B0 did not exist,
-origin/master started at B1, moved to B2 and then B, and you forked
-your topic at origin/master^ when origin/master was B1; the shape of
-the history would be the same as above, without B0, and the parent
-of B1 is what `git merge-base origin/master topic` correctly finds,
-but the `--fork-point` mode will not, because it is not one of the
-commits that used to be at the tip of origin/master).
-
-
-See also
---------
-linkgit:git-rev-list[1],
-linkgit:git-show-branch[1],
-linkgit:git-merge[1]
-
-GIT
----
-Part of the linkgit:git[1] suite