www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dlibgit updated to libgit2 v0.19.0

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
https://github.com/AndrejMitrovic/dlibgit

These are the D bindings to the libgit2 library. libgit2 is a
versatile git library which can read/write loose git object files,
parse commits, tags, and blobs, do tree traversals, and much more.

The dlibgit master branch is now based on the recent libgit2 v0.19.0
release. The previous bindings were based on 0.17.0, and there have
been many new features introduced since then.

Note: The D-based samples have not yet been updated to v0.19.0, but
I'll work on this in the coming days.

Note: I might also look into making this a dub-aware package, if
that's something people want.

Licensing information:

libgit2 is licensed under a very permissive license (GPLv2 with a
special Linking Exception). This basically means that you can link it
(unmodified) with any kind of software without having to release its
source code.

dlibtgit github page: https://github.com/AndrejMitrovic/dlibgit
libgit2 homepage: libgit2.github.com/
libgit2 repo: https://github.com/libgit2/libgit2/
Jun 26 2013
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 26.06.2013 21:36, schrieb Andrej Mitrovic:
 https://github.com/AndrejMitrovic/dlibgit

 These are the D bindings to the libgit2 library. libgit2 is a
 versatile git library which can read/write loose git object files,
 parse commits, tags, and blobs, do tree traversals, and much more.

 The dlibgit master branch is now based on the recent libgit2 v0.19.0
 release. The previous bindings were based on 0.17.0, and there have
 been many new features introduced since then.

 Note: The D-based samples have not yet been updated to v0.19.0, but
 I'll work on this in the coming days.

 Note: I might also look into making this a dub-aware package, if
 that's something people want.
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 Unfortunately I never got to finish it completely, which is why I didn't make a pull request yet. But anyway, since 0.19.0 now contains the latest features, I might as well drop my fork and point the registry to your repository. You can take my package.json as a template: https://github.com/s-ludwig/dlibgit/blob/master/package.json It should probably get a "targetType": "none" field, since it's header-only, and "authors"/"copyright" fields are missing.
Jun 26 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/26/13, S=F6nke Ludwig <sludwig 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. 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".
Jun 26 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/26/13, S=F6nke Ludwig <sludwig 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)?
 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.
Jun 26 2013
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.06.2013 00:01, schrieb Andrej Mitrovic:
 On 6/26/13, Sönke Ludwig <sludwig 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 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?
Jun 27 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/28/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:
 That sounds great. I wonder if it makes sense to make a separate Deimos
 package for the C bindings?
I'm not fond of Deimos. In fact I think projects like dub largerly make Deimos largely irrelevant, because discovery of bindings is automatable. Also, Deimos has no reviewing effort, it's just Walter who hits the pull button on demand (and often several weeks after being notified). Deimos is an overhead which provides no benefits. It was supposed to be used to make discovery easy, but discovery can be done through a wiki, or dlang.org, or an automated process (dub).
Jun 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 28 June 2013 at 16:00:57 UTC, Andrej Mitrovic wrote:
 Deimos is an overhead which provides no benefits. It was 
 supposed to
 be used to make discovery easy, but discovery can be done 
 through a
 wiki, or dlang.org, or an automated process (dub).
I suspect with time Deimos will be completely superseeded by "dub" or whatever tool becomes standard package manager for D. However, it should not be simply discarded because: 1) right now dub is not an official dlang.org project, but Deimos is 2) it is a certain brand name which gives promises about aggregated bindings - all Deimos bindings are thin 1-to-1 reflections of their C origin. In that sense, I would have expected Deimos become part of dub registry at some point, preferrably as a separate package category. But they should not loose identity of Deimos project.
Jun 28 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2013 9:10 AM, Dicebot wrote:
 On Friday, 28 June 2013 at 16:00:57 UTC, Andrej Mitrovic wrote:
 Deimos is an overhead which provides no benefits. It was supposed to
 be used to make discovery easy, but discovery can be done through a
 wiki, or dlang.org, or an automated process (dub).
Deimos provides all the usual benefits of using github for projects. I used to maintain a page with a list of links to D related projects. It regularly suffered from links going out of date, domain names being abandoned and then taken up by porn sites, projects simply disappearing, no consistent way for users to contribute to those projects, etc.
 I suspect with time Deimos will be completely superseeded by "dub" or whatever
 tool becomes standard package manager for D. However, it should not be simply
 discarded because:

 1) right now dub is not an official dlang.org project, but Deimos is

 2) it is a certain brand name which gives promises about aggregated bindings -
 all Deimos bindings are thin 1-to-1 reflections of their C origin.

 In that sense, I would have expected Deimos become part of dub registry at some
 point, preferrably as a separate package category. But they should not loose
 identity of Deimos project.
https://github.com/D-Programming-Deimos
Jun 29 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/28/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:
 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.
Btw, do you have any opinion on whether the API should be struct-based or class-based? I'm thinking I'll probably have to worry about memory management, so either refcounted structs or final classes could be used one way or another (similar to CairoD). Btw, if you have any suggestions about the overall API design, or what you need in the D API that the C API doesn't support, do let me know.
Jun 28 2013