184 lines
		
	
	
		
			5.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
			
		
		
	
	
			184 lines
		
	
	
		
			5.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
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 checkout -b
 | 
						|
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---B1
 | 
						|
			/
 | 
						|
	---o---o---B2--o---o---o---B (origin/master)
 | 
						|
		\
 | 
						|
		 B3
 | 
						|
		  \
 | 
						|
		   Derived (topic)
 | 
						|
 | 
						|
where `origin/master` used to point at commits B3, B2, B1 and now it
 | 
						|
points at B, and your `topic` branch was started on top of it back
 | 
						|
when `origin/master` was at B3. This mode uses the reflog of
 | 
						|
`origin/master` to find B3 as the fork point, so that the `topic`
 | 
						|
can be rebased on top of the updated `origin/master` by:
 | 
						|
 | 
						|
    $ fork_point=$(git merge-base --fork-point origin/master topic)
 | 
						|
    $ git rebase --onto origin/master $fork_point topic
 | 
						|
 | 
						|
 | 
						|
See also
 | 
						|
--------
 | 
						|
linkgit:git-rev-list[1],
 | 
						|
linkgit:git-show-branch[1],
 | 
						|
linkgit:git-merge[1]
 | 
						|
 | 
						|
GIT
 | 
						|
---
 | 
						|
Part of the linkgit:git[1] suite
 |