mirror of
https://github.com/git/git
synced 2024-08-28 20:20:07 +00:00
![Philip Oakley](/assets/img/avatar_default.png)
The doc-tool stack does not always respect the 'tab = 8 spaces' rule, particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base and the Git generated html pages. Use just spaces within the block of the ascii art. Noticed when reviewing Junio's suggested update to `git merge-base` https://public-inbox.org/git/xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com/T/#u Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
|