Re: A note on merging conflicts..

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 1, 2006, 23:01 UTC
Message-ID: <Pine.LNX.4.63.0607020056300.29667@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7vzmftcd60.fsf@assigned-by-dhcp.cox.net>

Hi,

On Sat, 1 Jul 2006, Junio C Hamano wrote:

> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> 
> > I wonder why the two clear_commit_marks() calls at the end of
> > get_merge_bases() are not sufficient, though.

I wonder, too. In all of my tests, this call was sufficient to reset the marks. I really wonder what happens here. At least one of the three flags should be set in _any_ commit get_merge_bases() touches. Help!

> I missed to notice that Johannes had added those calls there; we
> should remove them from get_merge_bases().

As you hinted with your patch in another mail: no, we should not. Stuff them into an if(), yes. But the point of a library function is not to make it hard on users, but rather to make life easier. The user should _not_ have to investigate which loops to jump through to make use of this function several times.

> The normal case of git-merge-base calling get_merge_bases() once
> and exiting should NOT have to pay for the clean-up cost at all.

Note that this was partly the reason for my hesitation to propose this patch for inclusion already. If you make this function a library function, the main user is _not_ git-merge-base any more. Everybody can use it from now on.

Ciao, Dscho

P.S.: I was having to much fun tonight to investigate in detail... Sorry.