Re: Comments on recursive merge..

From: Junio C Hamano <junkio@cox.net>
Date: Nov 9, 2005, 10:20 UTC
Message-ID: <7v4q6mgm1l.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7v8xvyd2bh.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 11 quoted lines

> Linus Torvalds <torvalds@osdl.org> writes:
>
>> It does:
>>
>> 	struct commit *commit = pop_one_commit(list_p);
>> 	int still_interesting = !!interesting(*list_p);
>>
>> in that order: it looks whether there are any interesting commits left 
>> _after_ it has popped the top-of-stack.
>
> The problem is most of the time hidden,...

As you pointed out, still_interesting means "after we are done with this commit, do we still have something interesting to be processed?", and the later "extra < 0" check compensates for this. After I pop the last interesting commit, I still look at its parents and push them back into the list.

It seems to be doing the right thing after all. I hate to admit it, but I have been having hard time figuring out how this thing works X-<. In the meantime, I've checked commits from linux-2.6 history that have more than one merge-base candidates. "git-merge-base --all" and "git-show-branch --merge-base" give the same answer to all of them [*1*].

I do not think "git-show-branch --merge-base" can be any more efficient than "git-merge-base --all". It does _more_ things (probably unnecessary things as well). Pasky's number could be just an artifact of hot/cold cache difference.

[Footnote]

*1* Here are the commits I used from linux-2.6 repository that have more than one commits:

    ba9b543d5bec0a7605952e2ba501fb8b0f3b6407
    84ffa747520edd4556b136bdfc9df9eb1673ce12
    da28c12089dfcfb8695b6b555cdb8e03dda2b690
    3190186362466658f01b2e354e639378ce07e1a9
    0c168775709faa74c1b87f1e61046e0c51ade7f3
    0e396ee43e445cb7c215a98da4e76d0ce354d9d7
    467ca22d3371f132ee225a5591a1ed0cd518cb3d