On Fri, Oct 31, 2008 at 11:49:11PM +0000, Junio C Hamano wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > You are the end-user of the library, so it needs to suit you. Ok, > > you aren't the only end-user, but you and other developers like > > you... :-) > > I will be the end-user of the library because if we want libgit2 to be > anywhere close to successful, you should be able to port C-git to it. > > 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. It is great for processing > efficiency as long as you are a "run once and let exit(3) clean-up" type > of program, but is quite problematic otherwise. commit.flags that C-git > uses for traversal marker purposes, together with "who are parents and > children of this commit", should probably be kept inside traversal module, > if you want to make this truly reusable. 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. > By the way, I hate git_result_t. That should be "int", the most natural > integral type on the platform. I concur. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpT6xw8Ss9WP.pgp
Description: PGP signature
