Merge branch 'maint'

* maint:
  merge-base: Clarify the comments on post processing.
  Update the documentation for git-merge-base
This commit is contained in:
Junio C Hamano 2006-05-16 17:21:02 -07:00
commit 5c87a8c560
2 changed files with 20 additions and 7 deletions

View file

@ -8,16 +8,26 @@ git-merge-base - Finds as good a common ancestor as possible for a merge
SYNOPSIS
--------
'git-merge-base' <commit> <commit>
'git-merge-base' [--all] <commit> <commit>
DESCRIPTION
-----------
"git-merge-base" finds as good a common ancestor as possible. Given a
selection of equally good common ancestors it should not be relied on
to decide in any particular way.
"git-merge-base" finds as good a common ancestor as possible between
the two commits. That is, 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 a selection of equally good common ancestors it should not be
relied on to decide in any particular way.
The "git-merge-base" algorithm is still in flux - use the source...
OPTIONS
-------
--all::
Output all common ancestors for the two commits instead of
just one.
Author
------

View file

@ -82,8 +82,9 @@ static struct commit *interesting(struct commit_list *list)
* commit B.
*
*
* Another pathological example how this thing can fail to mark an ancestor
* of a merge base as UNINTERESTING without the postprocessing phase.
* Another pathological example how this thing used to fail to mark an
* ancestor of a merge base as UNINTERESTING before we introduced the
* postprocessing phase (mark_reachable_commits).
*
* 2
* H
@ -118,7 +119,9 @@ static struct commit *interesting(struct commit_list *list)
* D7 2 3 7 7 3 2 1 2
* E7 2 3 7 7 7 2 1 2
*
* and we end up showing E as an interesting merge base.
* and we ended up showing E as an interesting merge base.
* The postprocessing phase re-injects C and continues traversal
* to contaminate D and E.
*/
static int show_all = 0;