'\" t
.\" Title: git-merge-base
.\" Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
.\" Date: 01/04/2016
.\" Manual: Git Manual
.\" Source: Git 2.7.0
.\" Language: English
.\"
.TH "GIT\-MERGE\-BASE" "1" "01/04/2016" "Git 2\&.7\&.0" "Git Manual"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
git-merge-base \- Find as good common ancestors as possible for a merge
.SH "SYNOPSIS"
.sp
.nf
\fIgit merge\-base\fR [\-a|\-\-all] <commit> <commit>\&...
\fIgit merge\-base\fR [\-a|\-\-all] \-\-octopus <commit>\&...
\fIgit merge\-base\fR \-\-is\-ancestor <commit> <commit>
\fIgit merge\-base\fR \-\-independent <commit>\&...
\fIgit merge\-base\fR \-\-fork\-point <ref> [<commit>]
.fi
.sp
.SH "DESCRIPTION"
.sp
\fIgit merge\-base\fR finds best common ancestor(s) between two commits to use in a three\-way merge\&. One common ancestor is \fIbetter\fR 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 \fIbest common ancestor\fR, i\&.e\&. a \fImerge base\fR\&. Note that there can be more than one merge base for a pair of commits\&.
.SH "OPERATION MODES"
.sp
As the most common special case, specifying only two commits on the command line means computing the merge base between the given two commits\&.
.sp
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\&.
.sp
As a consequence, the \fImerge base\fR is not necessarily contained in each of the commit arguments if more than two commits are specified\&. This is different from \fBgit-show-branch\fR(1) when used with the \-\-merge\-base option\&.
.PP
\-\-octopus
.RS 4
Compute the best common ancestors of all supplied commits, in preparation for an n\-way merge\&. This mimics the behavior of
\fIgit show\-branch \-\-merge\-base\fR\&.
.RE
.PP
\-\-independent
.RS 4
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
\fIgit show\-branch \-\-independent\fR\&.
.RE
.PP
\-\-is\-ancestor
.RS 4
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\&.
.RE
.PP
\-\-fork\-point
.RS 4
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)\&.
.RE
.SH "OPTIONS"
.PP
\-a, \-\-all
.RS 4
Output all merge bases for the commits, instead of just one\&.
.RE
.SH "DISCUSSION"
.sp
Given two commits \fIA\fR and \fIB\fR, git merge\-base A B will output a commit which is reachable from both \fIA\fR and \fIB\fR through the parent relationship\&.
.sp
For example, with this topology:
.sp
.if n \{\
.RS 4
.\}
.nf
o\-\-\-o\-\-\-o\-\-\-B
/
\-\-\-o\-\-\-1\-\-\-o\-\-\-o\-\-\-o\-\-\-A
.fi
.if n \{\
.RE
.\}
.sp
the merge base between \fIA\fR and \fIB\fR is \fI1\fR\&.
.sp
Given three commits \fIA\fR, \fIB\fR and \fIC\fR, git merge\-base A B C will compute the merge base between \fIA\fR and a hypothetical commit \fIM\fR, which is a merge between \fIB\fR and \fIC\fR\&. For example, with this topology:
.sp
.if n \{\
.RS 4
.\}
.nf
o\-\-\-o\-\-\-o\-\-\-o\-\-\-C
/
/ o\-\-\-o\-\-\-o\-\-\-B
/ /
\-\-\-2\-\-\-1\-\-\-o\-\-\-o\-\-\-o\-\-\-A
.fi
.if n \{\
.RE
.\}
.sp
the result of git merge\-base A B C is \fI1\fR\&. This is because the equivalent topology with a merge commit \fIM\fR between \fIB\fR and \fIC\fR is:
.sp
.if n \{\
.RS 4
.\}
.nf
o\-\-\-o\-\-\-o\-\-\-o\-\-\-o
/ \e
/ o\-\-\-o\-\-\-o\-\-\-o\-\-\-M
/ /
\-\-\-2\-\-\-1\-\-\-o\-\-\-o\-\-\-o\-\-\-A
.fi
.if n \{\
.RE
.\}
.sp
and the result of git merge\-base A M is \fI1\fR\&. Commit \fI2\fR is also a common ancestor between \fIA\fR and \fIM\fR, but \fI1\fR is a better common ancestor, because \fI2\fR is an ancestor of \fI1\fR\&. Hence, \fI2\fR is not a merge base\&.
.sp
The result of git merge\-base \-\-octopus A B C is \fI2\fR, because \fI2\fR is the best common ancestor of all commits\&.
.sp
When the history involves criss\-cross merges, there can be more than one \fIbest\fR common ancestor for two commits\&. For example, with this topology:
.sp
.if n \{\
.RS 4
.\}
.nf
\-\-\-1\-\-\-o\-\-\-A
\e /
X
/ \e
\-\-\-2\-\-\-o\-\-\-o\-\-\-B
.fi
.if n \{\
.RE
.\}
.sp
both \fI1\fR and \fI2\fR are merge\-bases of A and B\&. Neither one is better than the other (both are \fIbest\fR merge bases)\&. When the \-\-all option is not given, it is unspecified which best one is output\&.
.sp
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\&.
.sp
.if n \{\
.RS 4
.\}
.nf
A=$(git rev\-parse \-\-verify A)
if test "$A" = "$(git merge\-base A B)"
then
\&.\&.\&. A is an ancestor of B \&.\&.\&.
fi
.fi
.if n \{\
.RE
.\}
.sp
In modern git, you can say this in a more direct way:
.sp
.if n \{\
.RS 4
.\}
.nf
if git merge\-base \-\-is\-ancestor A B
then
\&.\&.\&. A is an ancestor of B \&.\&.\&.
fi
.fi
.if n \{\
.RE
.\}
.sp
instead\&.
.SH "DISCUSSION ON FORK-POINT MODE"
.sp
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:
.sp
.if n \{\
.RS 4
.\}
.nf
o\-\-\-B1
/
\-\-\-o\-\-\-o\-\-\-B2\-\-o\-\-\-o\-\-\-o\-\-\-B (origin/master)
\e
B3
\e
Derived (topic)
.fi
.if n \{\
.RE
.\}
.sp
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:
.sp
.if n \{\
.RS 4
.\}
.nf
$ fork_point=$(git merge\-base \-\-fork\-point origin/master topic)
$ git rebase \-\-onto origin/master $fork_point topic
.fi
.if n \{\
.RE
.\}
.SH "SEE ALSO"
.sp
\fBgit-rev-list\fR(1), \fBgit-show-branch\fR(1), \fBgit-merge\fR(1)
.SH "GIT"
.sp
Part of the \fBgit\fR(1) suite