diff options
Diffstat (limited to 'third_party/git/Documentation/git-merge-base.txt')
| -rw-r--r-- | third_party/git/Documentation/git-merge-base.txt | 231 |
1 files changed, 0 insertions, 231 deletions
diff --git a/third_party/git/Documentation/git-merge-base.txt b/third_party/git/Documentation/git-merge-base.txt deleted file mode 100644 index 261d5c1164..0000000000 --- a/third_party/git/Documentation/git-merge-base.txt +++ /dev/null @@ -1,231 +0,0 @@ -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 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 |