Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 27, 2008, 15:02 UTC
Message-ID: <m3vdyrtloo.fsf@localhost.localdomain>
In-Reply-To: <20080727053324.b54fe48e.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

> Before this patch "git merge-base" accepted only 2 arguments, so
> only merge bases between 2 references could be computed.

Show 12 quoted lines

> +'git-merge-base' finds as good common ancestors as possible between
> +the first commit and the other commits. The default behavior is to
> +output only one as good as possible common ancestor, called a merge
> +base.
> +
> +For example, 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.
> +
> +Given three commits A, B and C, `git merge-base A B C` will output a
> +commit which is reachable through the parent relationship from both A
> +and B, or from both A and C.

I don't understand this complication. Isn't merge base (merge bases) for commits A, B and C simply least common ancestor (or ancestors) of commits A, B and C (with commits being included as their own ancestors)?

What are the results of "git merge-base" and "git merge-base --all" in the following situations?

For two commits:

      .---.---*---.---.---A
               \
                \-.---B

      .---m-----b---.---.---A
           \     \ /
            \     X
             \   / \
              \-a---.---.---B

For three commits:

      .---.---1---2---.---.---A
               \   \
                \   \-.---B
                 \
                  \---.---.---C

                    /-.---.---A
                   /
      .---.---1---2---.---.---B
               \
                \-.---.---.---C

-- 
Jakub Narebski
Poland
ShadeHawk on #git