On Jan 16, 2008 10:53 PM, Sverre Hvammen Johansen <hvammen@gmail.com> wrote:
quoted text
> We need to consider cases where the branch we are merging with is an
> ancestor or an descendant of HEAD.  The patch only take descendants
> into account.  There may also be more than one branch we are merging
> with.  All these cases must be considered.  In the case of an octopus, the
> cases are slightly more complicated.

I have been testing octopus merges and figured it is not very smart with
respect to fast forward.  I would like it to do a fast forward whenever it
makes sense to do that.  Consider the following:

     -- c1 -- A
   /              /  \
c0 -- c2 --      C
   \              \  /
     -- c3 -- B

A is a merge between c1 and c2, B is a merge between c2 and c3, and C is a
merge between A and B.

c1 merged with A does a fast forward to A, A merged with C does a fast forward
to C, but an octopus merge of c1 with A and C does not fast forward to
C.  I would
expect it to fast forward to C.  The commit graph above have several other cases
where an octopus merge can be reduced to a fast forward or a recursive merge.

I suggest a separate pass before we choose merge strategy.  Remove commits
that can be fast forwarded to any of the other commits from the
equation and fast
forward the current branch if possible.  The remaining commits are then taken
into consideration.  This may reduce the number of commits and thus result in
a fast forward or another merge strategy.

I intend to make the patch for the option --ff-only as simple as
possible, where it
will fail where more than two commits are involved.  If the above suggested pass
is implemented it should also take affect for --ff-only.

Does this make sense?

-- 
Sverre Hvammen Johansen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html