From: Junio C Hamano Date: Wed, 09 Nov 2005 06:10:30 GMT Subject: Re: Comments on recursive merge.. Message-ID: <7v7jbinyg9.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Linus Torvalds writes: > 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.