made the pack completely portable and wrote relevent bat files to go with it
This commit is contained in:
Draqoken
247
gitportable/mingw64/share/doc/git-doc/git-merge-base.adoc
Normal file
247
gitportable/mingw64/share/doc/git-doc/git-merge-base.adoc
Normal file
@@ -0,0 +1,247 @@
|
||||
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 the 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
|
||||
---------------
|
||||
|
||||
In 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
|
||||
of 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 switch -c
|
||||
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---B2
|
||||
/
|
||||
---o---o---B1--o---o---o---B (origin/master)
|
||||
\
|
||||
B0
|
||||
\
|
||||
D0---D1---D (topic)
|
||||
....
|
||||
|
||||
where `origin/master` used to point at commits B0, B1, B2 and now it
|
||||
points at B, and your `topic` branch was started on top of it back
|
||||
when `origin/master` was at B0, and you built three commits, D0, D1,
|
||||
and D, on top of it. Imagine that you now want to rebase the work
|
||||
you did on the topic on top of the updated origin/master.
|
||||
|
||||
In such a case, `git merge-base origin/master topic` would return the
|
||||
parent of B0 in the above picture, but B0^..D is *not* the range of
|
||||
commits you would want to replay on top of B (it includes B0, which
|
||||
is not what you wrote; it is a commit the other side discarded when
|
||||
it moved its tip from B0 to B1).
|
||||
|
||||
`git merge-base --fork-point origin/master topic` is designed to
|
||||
help in such a case. It takes not only B but also B0, B1, and B2
|
||||
(i.e. old tips of the remote-tracking branches your repository's
|
||||
reflog knows about) into account to see on which commit your topic
|
||||
branch was built and finds B0, allowing you to replay only the
|
||||
commits on your topic, excluding the commits the other side later
|
||||
discarded.
|
||||
|
||||
Hence
|
||||
|
||||
$ fork_point=$(git merge-base --fork-point origin/master topic)
|
||||
|
||||
will find B0, and
|
||||
|
||||
$ git rebase --onto origin/master $fork_point topic
|
||||
|
||||
will replay D0, D1, and D on top of B to create a new history of this
|
||||
shape:
|
||||
|
||||
....
|
||||
o---B2
|
||||
/
|
||||
---o---o---B1--o---o---o---B (origin/master)
|
||||
\ \
|
||||
B0 D0'--D1'--D' (topic - updated)
|
||||
\
|
||||
D0---D1---D (topic - old)
|
||||
....
|
||||
|
||||
A caveat is that older reflog entries in your repository may be
|
||||
expired by `git gc`. If B0 no longer appears in the reflog of the
|
||||
remote-tracking branch `origin/master`, the `--fork-point` mode
|
||||
obviously cannot find it and fails, avoiding to give a random and
|
||||
useless result (such as the parent of B0, like the same command
|
||||
without the `--fork-point` option gives).
|
||||
|
||||
Also, the remote-tracking branch you use the `--fork-point` mode
|
||||
with must be the one your topic forked from its tip. If you forked
|
||||
from an older commit than the tip, this mode would not find the fork
|
||||
point (imagine in the above sample history B0 did not exist,
|
||||
origin/master started at B1, moved to B2 and then B, and you forked
|
||||
your topic at origin/master^ when origin/master was B1; the shape of
|
||||
the history would be the same as above, without B0, and the parent
|
||||
of B1 is what `git merge-base origin/master topic` correctly finds,
|
||||
but the `--fork-point` mode will not, because it is not one of the
|
||||
commits that used to be at the tip of origin/master).
|
||||
|
||||
|
||||
See also
|
||||
--------
|
||||
linkgit:git-rev-list[1],
|
||||
linkgit:git-show-branch[1],
|
||||
linkgit:git-merge[1]
|
||||
|
||||
GIT
|
||||
---
|
||||
Part of the linkgit:git[1] suite
|
||||
Reference in New Issue
Block a user