blob: 87842e33f8aebc7d27fa732af1de15f0e4175c07 [file] [log] [blame]
Junio C Hamano1a4e8412005-12-27 08:17:231git-merge-base(1)
2=================
3
4NAME
5----
Junio C Hamano7c73c662007-01-19 00:37:506git-merge-base - Find as good common ancestors as possible for a merge
Junio C Hamano1a4e8412005-12-27 08:17:237
8
9SYNOPSIS
10--------
Junio C Hamano2db3e752010-09-03 21:33:0611[verse]
Junio C Hamanob77f8192011-05-05 01:30:3812'git merge-base' [-a|--all] <commit> <commit>...
13'git merge-base' [-a|--all] --octopus <commit>...
Junio C Hamano693e7092012-09-12 22:56:5314'git merge-base' --is-ancestor <commit> <commit>
Junio C Hamano2db3e752010-09-03 21:33:0615'git merge-base' --independent <commit>...
Junio C Hamano1a4e8412005-12-27 08:17:2316
17DESCRIPTION
18-----------
Junio C Hamano6959c6c2006-05-17 10:34:1119
Junio C Hamanofd9274d2009-08-05 21:21:3920'git merge-base' finds best common ancestor(s) between two commits to use
Junio C Hamano3f2f6e52008-08-21 10:34:2221in a three-way merge. One common ancestor is 'better' than another common
22ancestor if the latter is an ancestor of the former. A common ancestor
Junio C Hamanoec87f522008-12-10 08:35:2523that does not have any better common ancestor is a 'best common
Junio C Hamano3f2f6e52008-08-21 10:34:2224ancestor', i.e. a 'merge base'. Note that there can be more than one
Junio C Hamanoec87f522008-12-10 08:35:2525merge base for a pair of commits.
Junio C Hamano6959c6c2006-05-17 10:34:1126
Junio C Hamanob77f8192011-05-05 01:30:3827OPERATION MODE
28--------------
29
30As the most common special case, specifying only two commits on the
31command line means computing the merge base between the given two commits.
32
33More generally, among the two commits to compute the merge base from,
34one is specified by the first commit argument on the command line;
35the other commit is a (possibly hypothetical) commit that is a merge
36across all the remaining commits on the command line.
Junio C Hamano1a4e8412005-12-27 08:17:2337
Junio C Hamanofd9274d2009-08-05 21:21:3938As a consequence, the 'merge base' is not necessarily contained in each of the
39commit arguments if more than two commits are specified. This is different
40from linkgit:git-show-branch[1] when used with the `--merge-base` option.
41
Junio C Hamano2db3e752010-09-03 21:33:0642--octopus::
43Compute the best common ancestors of all supplied commits,
44in preparation for an n-way merge. This mimics the behavior
45of 'git show-branch --merge-base'.
46
47--independent::
48Instead of printing merge bases, print a minimal subset of
49the supplied commits with the same ancestors. In other words,
50among the commits given, list those which cannot be reached
51from any other. This mimics the behavior of 'git show-branch
52--independent'.
53
Junio C Hamano693e7092012-09-12 22:56:5354--is-ancestor::
55Check if the first <commit> is an ancestor of the second <commit>,
56and exit with status 0 if true, or with status 1 if not.
57Errors are signaled by a non-zero status that is not 1.
58
59
Junio C Hamanob77f8192011-05-05 01:30:3860OPTIONS
61-------
62-a::
63--all::
64Output all merge bases for the commits, instead of just one.
65
Junio C Hamano3f2f6e52008-08-21 10:34:2266DISCUSSION
67----------
68
69Given two commits 'A' and 'B', `git merge-base A B` will output a commit
70which is reachable from both 'A' and 'B' through the parent relationship.
71
72For example, with this topology:
73
74 o---o---o---B
75/
76---o---1---o---o---o---A
77
78the merge base between 'A' and 'B' is '1'.
79
80Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the
Junio C Hamanoec87f522008-12-10 08:35:2581merge base between 'A' and a hypothetical commit 'M', which is a merge
Junio C Hamano3f2f6e52008-08-21 10:34:2282between 'B' and 'C'. For example, with this topology:
83
84 o---o---o---o---C
85 /
86 / o---o---o---B
87 / /
88---2---1---o---o---o---A
89
90the result of `git merge-base A B C` is '1'. This is because the
91equivalent topology with a merge commit 'M' between 'B' and 'C' is:
92
93
94 o---o---o---o---o
95 / \
96 / o---o---o---o---M
97 / /
98---2---1---o---o---o---A
99
100and the result of `git merge-base A M` is '1'. Commit '2' is also a
101common ancestor between 'A' and 'M', but '1' is a better common ancestor,
102because '2' is an ancestor of '1'. Hence, '2' is not a merge base.
103
Junio C Hamanob77f8192011-05-05 01:30:38104The result of `git merge-base --octopus A B C` is '2', because '2' is
105the best common ancestor of all commits.
106
Junio C Hamano3f2f6e52008-08-21 10:34:22107When the history involves criss-cross merges, there can be more than one
Junio C Hamanoec87f522008-12-10 08:35:25108'best' common ancestor for two commits. For example, with this topology:
Junio C Hamano3f2f6e52008-08-21 10:34:22109
110 ---1---o---A
111 \ /
112 X
113 / \
114 ---2---o---o---B
115
Junio C Hamanoec87f522008-12-10 08:35:25116both '1' and '2' are merge-bases of A and B. Neither one is better than
117the other (both are 'best' merge bases). When the `--all` option is not given,
Junio C Hamano3f2f6e52008-08-21 10:34:22118it is unspecified which best one is output.
Junio C Hamano1a4e8412005-12-27 08:17:23119
Junio C Hamano693e7092012-09-12 22:56:53120A common idiom to check "fast-forward-ness" between two commits A
121and B is (or at least used to be) to compute the merge base between
122A and B, and check if it is the same as A, in which case, A is an
123ancestor of B. You will see this idiom used often in older scripts.
124
125A=$(git rev-parse --verify A)
126if test "$A" = "$(git merge-base A B)"
127then
128... A is an ancestor of B ...
129fi
130
131In modern git, you can say this in a more direct way:
132
133if git merge-base --is-ancestor A B
134then
135... A is an ancestor of B ...
136fi
137
138instead.
139
140
Junio C Hamano2db3e752010-09-03 21:33:06141See also
142--------
143linkgit:git-rev-list[1],
144linkgit:git-show-branch[1],
145linkgit:git-merge[1]
146
Junio C Hamano1a4e8412005-12-27 08:17:23147GIT
148---
Junio C Hamanof7c042d2008-06-06 22:50:53149Part of the linkgit:git[1] suite