From: Karl Hasselström <kha@treskal.com>
Date: Thu, 19 Jun 2008 08:21:56 GMT
Subject: Re: git-rerere observations and feature suggestions
Message-ID: <20080619082156.GB12727@diana.vm.bytemark.co.uk>
In-Reply-To: <7v7iclx4nw.fsf@gitster.siamese.dyndns.org>

On 2008-06-19 00:30:43 -0700, Junio C Hamano wrote:

> Karl Hasselström <kha@treskal.com> writes:
>
> > So how many parents can a commit have, exactly? Is there a hard
> > limit somewhere, or just a point beyond which some git tools will
> > start behaving strangely?
>
> There is no hard limit at the data structure level.
>
> git-commit-tree has a hard limit of accepting 16 parents. git-blame
> has the same 16-parent limit while following the history (but the
> one in 'next' has lifted the latter limitation).

Thanks.

> But that is purely academic. Anybody who does an octopus with more
> than 8 legs should get his head examined ;-).

Catalin and I are tossing ideas around for how to represent the
history of an StGit patch stack (using a git commit for each log
entry). One complication is that we have to keep references to all
unapplied patches so that gc will leave them alone (and so that they
will get carried along during a pull, in the future). And the number
of unapplied patches is potentially large, so I thought we'd be going
to have to make a tree of "merge" commits to connect them all up.

(What we'd really like, of course, is a way to refer to a set of
commits such that they are guaranteed to be reachable (in the gc and
pull sense), but not considered "parents".)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle