dlibgit updated to libgit2 v0.19.0

Sönke Ludwig sludwig at outerproduct.org
Thu Jun 27 23:09:54 PDT 2013


Am 27.06.2013 00:01, schrieb Andrej Mitrovic:
> On 6/26/13, Sönke Ludwig <sludwig at outerproduct.org> wrote:
>> I've been using dlibgit since some time
> 
> Btw, I'm curious what kind of work you've done using dlibgit (if it's
> ok to ask)?

It's a CI server that heavily relies on GIT and DUB to provide an almost
configuration free experience. It's still WIP and just planned for
internal use for now, though.

> 
>> I've already registered a fork with (partially) updated bindings for the
>> master version of libgit2: http://registry.vibed.org/packages/dlibgit
> 
> I saw some of your commits now. I'm happy to see that we no longer
> need bitfields in v0.19.0, and it seems most of the inline functions
> in libgit2 are gone, making porting easier. Those libgit devs are
> doing a great job.
> 

Indeed, it is nice to see the progress, also in terms of functionality
and stability and even though they changed half of the API since the
last release. The only thing that is lacking is the high level
documentation (and sometimes the API docs). I had to do a lot of
research and reverse engineering to be able to do some slightly more
advanced things (mostly related to submodules). A nice higher level D
API on top would be a godsend for new users.

> On 6/26/13, Sönke Ludwig <sludwig at outerproduct.org> wrote:
>> Great to hear. I've been using dlibgit since some time and actually I've
>> already registered a fork with (partially) updated bindings for the
>> master version of libgit2: http://registry.vibed.org/packages/dlibgit
> 
> Ah, didn't know that. For now you may want to hold on to that package
> until I port the v0.17 samples to v0.19, to verify the new bindings
> work properly.

Ok, I'll also test them on our stuff when I get the time.

> 
> Btw, the reason why I've moved everything under the "git.c" package is
> because at some point I want to implement either a class or
> struct-based D API around the C API, so it's easier to use from client
> code.
> 
> The new D API will use modules such as "git.branch" while the C-based
> API "git.c.branch".

That sounds great. I wonder if it makes sense to make a separate Deimos
package for the C bindings?


More information about the Digitalmars-d-announce mailing list