$ ./merge_base

usage: merge_base <commitRev> <commitRev>
   or: merge_base --independent <commitRev>...
   or: merge_base --is-ancestor <commitRev> <commitRev>

    (no option)       lists the best common ancestors of the two passed commits
    --independent     list commits not reachable from the others
    --is-ancestor     is the first one ancestor of the other?

$ ./merge_base --help

NAME:
   merge_base - Lists the best common ancestors of the two passed commit revisions

SYNOPSIS:
 usage: merge_base <commitRev> <commitRev>
    or: merge_base --independent <commitRev>...
    or: merge_base --is-ancestor <commitRev> <commitRev>

DESCRIPTION:
    merge_base 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.

--independent
    List the sub group 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, merge_base 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 from another feature
    branches there can be also more than one common anvestor. 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
    can not be reached from 2, nor the opposite.