| package main |
| |
| const helpLongMsg = ` |
| NAME: |
| %_COMMAND_NAME_% - Lists the best common ancestors of the two passed commit revisions |
| |
| SYNOPSIS: |
| usage: %_COMMAND_NAME_% <path> <commitRev> <commitRev> |
| or: %_COMMAND_NAME_% <path> --independent <commitRev>... |
| or: %_COMMAND_NAME_% <path> --is-ancestor <commitRev> <commitRev> |
| |
| params: |
| <path> Path to the git repository |
| <commitRev> Git revision as supported by go-git |
| |
| DESCRIPTION: |
| %_COMMAND_NAME_% finds the best common ancestor(s) between two commits. 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. |
| Commits that does not share a common history has no common ancestors. |
| |
| OPTIONS: |
| As the most common special case, specifying only two commits on the command line means computing the merge base between the given two commits. |
| If there is no shared history between the passed commits, there won't be a merge-base, and the command will exit with status 1. |
| |
| --independent |
| List the subgroup from the passed commits, that cannot be reached from any other of the passed ones. In other words, it prints a minimal subset of the supplied commits with the same ancestors. |
| |
| --is-ancestor |
| Check if the first commit is an ancestor of the second one, 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. |
| |
| DISCUSSION: |
| Given two commits A and B, %_COMMAND_NAME_% A B will output a commit which is the best common ancestor of both, what means that is reachable from both A and B through the parent relationship. |
| |
| For example, with this topology: |
| |
| o---o---o---o---B |
| / / |
| ---3---2---o---1---o---A |
| |
| the merge base between A and B is 1. |
| |
| With the given topology 2 and 3 are also common ancestors of A and B, but they are not the best ones because they can be also reached from 1. |
| |
| When the history involves cross-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 |
| |
| When the history involves feature branches depending on other feature branches there can be also more than one common ancestor. For example: |
| |
| |
| o---o---o |
| / \ |
| 1---o---A \ |
| / / \ |
| ---o---o---2---o---o---B |
| |
| In both examples, both 1 and 2 are merge-bases of A and B for each situation. |
| Neither one is better than the other (both are best merge bases) because 1 cannot be reached from 2, nor the opposite. |
| ` |