Re: libgit2 - a true git library

From: Andreas Ericsson <ae@op5.se>
Date: Nov 1, 2008, 18:44 UTC
Message-ID: <490CA37C.1070107@op5.se>
In-Reply-To: <20081101173042.GE26229@artemis.corp>

Pierre Habouzit wrote:

Show 10 quoted lines

> On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote:
>> How about this?
>>
>> http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
> 
> FWIW I've read what you say about types, while this is good design to
> make things abstract, accessors are slower _and_ disallow many
> optimizations as it's a function call and that it may clobber all your
> pointers values.
>

Accessors are very nifty for one thing though; With a debugging flag, you can use an accessor-function, while without that debugging flag you can use a macro instead of a function. In other words, you use the compiler as a sort of sanity-checker that you're only accessing the variables through the proper macros.

This method introduces a bit of extra code (50% of which is always dead) for each struct it's used on, but it makes debugging large-ish pieces of software relatively simple, since access to all object types is controlled through the use of macros.

Show 5 quoted lines

> For types that _will_ be in the tight loops, we must make the types
> explicit or it'll bite us hard performance-wise. I'm thinking what is
> "struct object" or "struct commit" in git.git. It's likely that we will
> loose a *lot* of those types are opaque.
>

The last sentence doesn't parse. I assume you mean "if those types are..", in which case it'll be solved by using accessor-macros and forward-declaring the structs.

Show 12 quoted lines

> struct object in git has not changed since 2006.06. struct commit hasn't
> since 2005.04 if you ignore { unsigned int indegree; void *util; } that
> if I'm correct are annotations, and is a problem we (I think) have to
> address differently anyways (I gave my proposal on this, I'm eager to
> hear about what other think on the subject). So if in git.git that _is_
> a moving target we have had a 2 year old implementation for those types,
> it's that they're pretty well like this.
> 
> It's IMNSHO on the matter that core structures of git _will_ have to be
> made explicit. I'm thinking objects and their "subtypes" (commits,
> trees, blobs). Maybe a couple of things on the same vein.
>

I agree. "git_commit", "git_tree", "git_blob" and "git_tag" can almost certainly be set in stone straight away.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231