Christian Couder <chriscool@xxxxxxxxxxxxx> writes:
> Before this patch "git merge-base" accepted only 2 arguments, so
> only merge bases between 2 references could be computed.
> +'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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
