Re: libgit2 - a true git library

From: Shawn O. Pearce <spearce@spearce.org>
Date: Nov 1, 2008, 00:19 UTC
Message-ID: <20081101001926.GF14786@spearce.org>
In-Reply-To: <20081101000213.GB29036@artemis.corp>

Pierre Habouzit <madcoder@debian.org> wrote:

Show 16 quoted lines

> On Fri, Oct 31, 2008 at 11:49:11PM +0000, Junio C Hamano wrote:
> > 
> > I understand that the apidocs/ is a very early work-in-progress, but
> > still, it bothers me that it is unclear to me what lifetime rules are in
> > effect on the in-core objects.  For example, in C-git, commit objects are
> > not just parsed but are modified in place as history is traversed
> > (e.g. their flags smudged and their parents simplified).  You have "flags"
> > field in commit, which implies to me that the design shares this same
> > "modified by processing in-place" assumption.
> 
> I don't think it's impossible to have something efficient without this
> kind of hacks. You just need to dissociate the objects from their
> annotations, though use some kind of allocator that allow numbering of
> the objects, and use that number as a lookup in an array of annotations.
> It will require pool allocators for the annotations, but that should
> work fine and efficientely.

Interesting approach.  I don't know why I didn't think of that one.

You'll still need to be able to toss parts of the git graph though. If you just pin everything in memory under a single global object table you'll run server processes out of memory as they chug through large numbers of repositories.

> > By the way, I hate git_result_t.  That should be "int", the most natural
> > integral type on the platform.
> 
> I concur.

int it is then.

-- 
Shawn.