Re: Comments on recursive merge..

From: Junio C Hamano <junkio@cox.net>
Date: Nov 9, 2005, 06:10 UTC
Message-ID: <7v7jbinyg9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0511081614140.3247@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 16 quoted lines

> In general, you need to keep track of one bit per ref, and since we have 
> a 32-bit "flags" word and need a couple of bits for other maintenance 
> info, pretty much anything that figures out common heads will be limited 
> some way. 
>
> This is only a limit for the "and" logic - the "or" logic (if we implement 
> it) will just share the same status bit for all the refs that are "ored 
> together" and thus has no limits. 
>
> Oh, and the "and" logic can be extended by running the program multiple 
> times, so it's not a "hard" limit, it's just an issue of convenience.
>
> That said, anybody who ever does an octopus of more than just a few heads 
> deserves to be shot, so I don't think the limit should matter. The 
> recursive strategy should only add the "or" kind of refs, and it 
> shouldn't be a problem (apart from just how to describe them).

Come to think of it, git-merge-octopus does AND. If I am merging topic branches 1, 2, 3,... N into my master, internally it does an equivalent of merging 1 into master, then 2 into the result, then C into that result,..., and it uses merge-base of all the heads merged so far and the original master to pivot on.

And I think this is *wrong*. The merge base of each step when merging head N does not have to be older than merge base of the original master and head N, but currently that is not what it does. I should be ORing them ideally, but even if I do not, I should be able to just use the merge base of head N and original master.