From: Andreas Ericsson Date: Fri, 31 Oct 2008 21:59:47 GMT Subject: Re: libgit2 - a true git library Message-ID: <490B7FD3.8060003@op5.se> In-Reply-To: <20081031174745.GA4058@artemis.corp> Pierre Habouzit wrote: > On Fri, Oct 31, 2008 at 05:07:04PM +0000, Shawn O. Pearce wrote: >> During the GitTogether we were kicking around the idea of a ground-up >> implementation of a Git library. This may be easier than trying >> to grind down git.git into a library, as we aren't tied to any >> of the current global state baggage or the current die() based >> error handling. >> >> I've started an _extremely_ rough draft. The code compiles into a >> libgit.a but it doesn't even implement what it describes in the API, >> let alone a working Git implementation. Really what I'm trying to >> incite here is some discussion on what the API looks like. > > I know this isn't actually helping a lot to define the real APIs, but we > should really not repeat current git mistakes and have a really uniform > APIs, meaning that first we must decide: > * proper namespacing (e.g. OBJ_* looks like failure to me, it's a way > too common prefix); > As it's the git-lib, all public functions should almost certainly be prefixed with "git" or "git_". I favor "git_". > * proper public "stuff" naming (I e.g. realy like types names -- not > struct or enum tags, that I don't really care -- ending with _t as > it helps navigating source. > *_t types are reserved by POSIX for future implementations, so that's a no-go (although I doubt POSIX will ever make types named git_*_t). Apart from that, please consider reading Ulrich Drepper's musings on library design at http://people.redhat.com/drepper/goodpractice.pdf It's pretty short but brings up nearly all the crucial points one really don't want to forget. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231