Pierre Habouzit <madcoder@xxxxxxxxxx> wrote: > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
