Re: Comments on recursive merge..

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 9, 2005, 00:18 UTC
Message-ID: <Pine.LNX.4.64.0511081614140.3247@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.63.0511090017370.28256@wbgn013.biozentrum.uni-wuerzburg.de>

On Wed, 9 Nov 2005, Johannes Schindelin wrote:

Show 8 quoted lines

> 
> On Tue, 8 Nov 2005, Linus Torvalds wrote:
> 
> > Junio, that points out that "git-merge-base" is another program that could 
> > just be removed, since it's really supreceded by git-show-branch. Or did I 
> > miss something?
> 
> IIRC, git-show-branch has a limit on the number of refs it can take.

Well, git-merge-base does too. git-merge-base only takes two refs ;)

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).

		Linus