Re: A note on merging conflicts..

[Rene Scharfe <rene.scharfe@lsrfire.ath.cx>]

Junio C Hamano schrieb:
> I suspect this has the same problem I pointed out to Kristian's 
> attempt to make git-branch a built-in.
> 
> Subject: Re: [PATCH] Implement git-branch and git-merge-base as
> built-ins. Date: Thu, 08 Jun 2006 11:53:48 -0700 Message-ID:
> <7vverbsclf.fsf@assigned-by-dhcp.cox.net>
> 
> Namely, merge-base code is not set up to be called more than once
> without cleaning things up.

Eek!  This is not a nice interface.  Your example IDs from the your mail
to Kristian:

   $ ./git-rev-list 89719209...262a6ef7 66ae0c77...ced9456a | wc
        75      75    3075
   $ git-rev-list 89719209 262a6ef7 \
     --not $(git-merge-base --all 89719209 262a6ef7) \
     --not 66ae0c77 ced9456a \
     --not $(git-merge-base --all 66ae0c77 ced9456a) | wc
        75      75    3075

   $ ./git-rev-list 66ae0c77...ced9456a 89719209...262a6ef7 | wc
        76      76    3116
   $ git-rev-list 66ae0c77 ced9456a \
     --not $(git-merge-base --all 66ae0c77 ced9456a) \
     --not 89719209 262a6ef7 \
     --not $(git-merge-base --all 89719209 262a6ef7) | wc
        75      75    3075

Yep, that doesn't seem right.  The additional line is 262a6ef (which is
the merge base for 66ae0c77 and ced9456a btw.).  The other 4x 75 lines
match.

I wonder why the two clear_commit_marks() calls at the end of
get_merge_bases() are not sufficient, though.

René