]>
Commit | Line | Data |
---|---|---|
2cf565c5 DG |
1 | git-merge-base(1) |
2 | ================= | |
2cf565c5 DG |
3 | |
4 | NAME | |
5 | ---- | |
c3f0baac | 6 | git-merge-base - Find as good common ancestors as possible for a merge |
2cf565c5 DG |
7 | |
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
a1e0ad78 | 11 | [verse] |
57294824 VR |
12 | 'git merge-base' [-a|--all] <commit> <commit>... |
13 | 'git merge-base' [-a|--all] --octopus <commit>... | |
5907cda1 | 14 | 'git merge-base' --is-ancestor <commit> <commit> |
a1e0ad78 | 15 | 'git merge-base' --independent <commit>... |
d96855ff | 16 | 'git merge-base' --fork-point <ref> [<commit>] |
2cf565c5 DG |
17 | |
18 | DESCRIPTION | |
19 | ----------- | |
2aa83961 | 20 | |
995bdc73 | 21 | 'git merge-base' finds best common ancestor(s) between two commits to use |
99f1c04b JH |
22 | in a three-way merge. One common ancestor is 'better' than another common |
23 | ancestor if the latter is an ancestor of the former. A common ancestor | |
29b802aa | 24 | that does not have any better common ancestor is a 'best common |
99f1c04b | 25 | ancestor', i.e. a 'merge base'. Note that there can be more than one |
29b802aa | 26 | merge base for a pair of commits. |
2aa83961 | 27 | |
d96855ff JH |
28 | OPERATION MODES |
29 | --------------- | |
ded7e049 JN |
30 | |
31 | As the most common special case, specifying only two commits on the | |
32 | command line means computing the merge base between the given two commits. | |
33 | ||
34 | More generally, among the two commits to compute the merge base from, | |
35 | one is specified by the first commit argument on the command line; | |
36 | the other commit is a (possibly hypothetical) commit that is a merge | |
37 | across all the remaining commits on the command line. | |
2cf565c5 | 38 | |
f621a845 MG |
39 | As a consequence, the 'merge base' is not necessarily contained in each of the |
40 | commit arguments if more than two commits are specified. This is different | |
41 | from linkgit:git-show-branch[1] when used with the `--merge-base` option. | |
42 | ||
aa8f98c1 JN |
43 | --octopus:: |
44 | Compute the best common ancestors of all supplied commits, | |
45 | in preparation for an n-way merge. This mimics the behavior | |
46 | of 'git show-branch --merge-base'. | |
47 | ||
a1e0ad78 JN |
48 | --independent:: |
49 | Instead of printing merge bases, print a minimal subset of | |
50 | the supplied commits with the same ancestors. In other words, | |
51 | among the commits given, list those which cannot be reached | |
52 | from any other. This mimics the behavior of 'git show-branch | |
53 | --independent'. | |
54 | ||
5907cda1 JH |
55 | --is-ancestor:: |
56 | Check if the first <commit> is an ancestor of the second <commit>, | |
57 | and exit with status 0 if true, or with status 1 if not. | |
58 | Errors are signaled by a non-zero status that is not 1. | |
59 | ||
d96855ff JH |
60 | --fork-point:: |
61 | Find the point at which a branch (or any history that leads | |
62 | to <commit>) forked from another branch (or any reference) | |
63 | <ref>. This does not just look for the common ancestor of | |
64 | the two commits, but also takes into account the reflog of | |
65 | <ref> to see if the history leading to <commit> forked from | |
66 | an earlier incarnation of the branch <ref> (see discussion | |
67 | on this mode below). | |
5907cda1 | 68 | |
ded7e049 JN |
69 | OPTIONS |
70 | ------- | |
71 | -a:: | |
72 | --all:: | |
73 | Output all merge bases for the commits, instead of just one. | |
74 | ||
99f1c04b JH |
75 | DISCUSSION |
76 | ---------- | |
77 | ||
78 | Given two commits 'A' and 'B', `git merge-base A B` will output a commit | |
79 | which is reachable from both 'A' and 'B' through the parent relationship. | |
80 | ||
81 | For example, with this topology: | |
82 | ||
83 | o---o---o---B | |
84 | / | |
85 | ---o---1---o---o---o---A | |
86 | ||
87 | the merge base between 'A' and 'B' is '1'. | |
88 | ||
89 | Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the | |
29b802aa | 90 | merge base between 'A' and a hypothetical commit 'M', which is a merge |
99f1c04b JH |
91 | between 'B' and 'C'. For example, with this topology: |
92 | ||
93 | o---o---o---o---C | |
94 | / | |
95 | / o---o---o---B | |
96 | / / | |
97 | ---2---1---o---o---o---A | |
98 | ||
99 | the result of `git merge-base A B C` is '1'. This is because the | |
100 | equivalent topology with a merge commit 'M' between 'B' and 'C' is: | |
101 | ||
102 | ||
103 | o---o---o---o---o | |
104 | / \ | |
105 | / o---o---o---o---M | |
106 | / / | |
107 | ---2---1---o---o---o---A | |
108 | ||
109 | and the result of `git merge-base A M` is '1'. Commit '2' is also a | |
110 | common ancestor between 'A' and 'M', but '1' is a better common ancestor, | |
111 | because '2' is an ancestor of '1'. Hence, '2' is not a merge base. | |
112 | ||
57294824 VR |
113 | The result of `git merge-base --octopus A B C` is '2', because '2' is |
114 | the best common ancestor of all commits. | |
115 | ||
99f1c04b | 116 | When the history involves criss-cross merges, there can be more than one |
29b802aa | 117 | 'best' common ancestor for two commits. For example, with this topology: |
99f1c04b JH |
118 | |
119 | ---1---o---A | |
120 | \ / | |
121 | X | |
122 | / \ | |
123 | ---2---o---o---B | |
124 | ||
29b802aa RW |
125 | both '1' and '2' are merge-bases of A and B. Neither one is better than |
126 | the other (both are 'best' merge bases). When the `--all` option is not given, | |
99f1c04b | 127 | it is unspecified which best one is output. |
2cf565c5 | 128 | |
5907cda1 JH |
129 | A common idiom to check "fast-forward-ness" between two commits A |
130 | and B is (or at least used to be) to compute the merge base between | |
131 | A and B, and check if it is the same as A, in which case, A is an | |
132 | ancestor of B. You will see this idiom used often in older scripts. | |
133 | ||
134 | A=$(git rev-parse --verify A) | |
135 | if test "$A" = "$(git merge-base A B)" | |
136 | then | |
137 | ... A is an ancestor of B ... | |
138 | fi | |
139 | ||
140 | In modern git, you can say this in a more direct way: | |
141 | ||
142 | if git merge-base --is-ancestor A B | |
143 | then | |
144 | ... A is an ancestor of B ... | |
145 | fi | |
146 | ||
147 | instead. | |
148 | ||
d96855ff JH |
149 | Discussion on fork-point mode |
150 | ----------------------------- | |
151 | ||
152 | After working on the `topic` branch created with `git checkout -b | |
153 | topic origin/master`, the history of remote-tracking branch | |
154 | `origin/master` may have been rewound and rebuilt, leading to a | |
155 | history of this shape: | |
156 | ||
157 | o---B1 | |
158 | / | |
159 | ---o---o---B2--o---o---o---B (origin/master) | |
160 | \ | |
161 | B3 | |
162 | \ | |
163 | Derived (topic) | |
164 | ||
165 | where `origin/master` used to point at commits B3, B2, B1 and now it | |
166 | points at B, and your `topic` branch was started on top of it back | |
167 | when `origin/master` was at B3. This mode uses the reflog of | |
168 | `origin/master` to find B3 as the fork point, so that the `topic` | |
169 | can be rebased on top of the updated `origin/master` by: | |
170 | ||
171 | $ fork_point=$(git merge-base --fork-point origin/master topic) | |
172 | $ git rebase --onto origin/master $fork_point topic | |
173 | ||
5907cda1 | 174 | |
1846e9ed JN |
175 | See also |
176 | -------- | |
177 | linkgit:git-rev-list[1], | |
178 | linkgit:git-show-branch[1], | |
179 | linkgit:git-merge[1] | |
180 | ||
2cf565c5 DG |
181 | GIT |
182 | --- | |
9e1f0a85 | 183 | Part of the linkgit:git[1] suite |