Re: libgit2 - a true git library

[Bruno Santos <nayart3@gmail.com>]

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.
> 
> API Docs:
> http://www.spearce.org/projects/scm/libgit2/apidocs/html/modules.html
> 
> Source Code Clone URL:
> http://www.spearce.org/projects/scm/libgit2/libgit2.git
> 

We should take the opportunity a make it more portable. Instead of using
the posix api directly we should warp it in "git_" APIs. And be carefull
with certain APIs like fork or fork+exec and instead provided a more
generic solution: for fork one that would use the best solution in the
given platform, either by forking or threading; and for fork+exec a
generic create_process/run_command.


Here's an example, for the 'read' API, on how we can simply do this
without worries for the posix crowd:

ssize_t git_read(git_fildes_t fildes, void* buf, size_t bufsize);

Were git_fildes_t would be an int for posix and an HANDLE for win32.
For the posix case git_read can be simply inlined and we get zero overhead:

static inline ssize_t git_read(git_fildes_t fildes, void *buf,
			size_t bufsize)
{
	return read(fildes, buf, bufsize);
}

And for the win32 case it would be much more easier to implement the
equivalent, something like:

ssize_t git_read(git_fildes_t fildes, void *buf, size_t bufsize)
{
	DWORD rd;

	if (!ReadFile(fildes, buf, bufsize, &rd, NULL)) {
		//translate win32 error to errno
		return -1;
	}
	return rd;
}


Of course, there is also the issue of using the c runtime on win32, but
that problem can be easily solved outside git, provided that we don't
use a 'fileno' like API.



Bruno Santos