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