Re: A note on merging conflicts..

Rene Scharfe [off-list ref] writes:

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

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

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.

Hi,

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

Rene Scharfe [off-list ref] writes:

quoted

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.