'\" 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: 09/02/2016 .\" Manual: Git Manual .\" Source: Git 2.10.0 .\" Language: English .\" .TH "GIT\-MERGE\-BASE" "1" "09/02/2016" "Git 2\&.10\&.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 \fB\-\-merge\-base\fR 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, \fBgit merge\-base A B\fR 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, \fBgit merge\-base A B C\fR 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 \fBgit merge\-base A B C\fR 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 \fBgit merge\-base A M\fR 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 \fBgit merge\-base \-\-octopus A B C\fR 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 \fB\-\-all\fR 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 \fBtopic\fR branch created with \fBgit checkout \-b topic origin/master\fR, the history of remote\-tracking branch \fBorigin/master\fR 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 \fBorigin/master\fR used to point at commits B3, B2, B1 and now it points at B, and your \fBtopic\fR branch was started on top of it back when \fBorigin/master\fR was at B3\&. This mode uses the reflog of \fBorigin/master\fR to find B3 as the fork point, so that the \fBtopic\fR can be rebased on top of the updated \fBorigin/master\fR 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