Weekly Edition
Return to the Development page
| |||||||||||||
libgit2 - a git library
The libgit2 project has hit the
net. "libgit2 is a portable, pure C implementation of the Git core
methods provided as a re-entrant linkable library with a solid API,
allowing you to write native speed custom Git applications in any language
which supports C bindings." Bindings for Ruby, Python, and Erlang
are available now. (Thanks to Don Marti).
(Log in to post comments)
libgit2 - a git library Posted Dec 2, 2010 15:08 UTC (Thu) by nix (subscriber, #2304) [Link]
A C program that uses waf as its build system? Strange. "My mommy thought I would grow up to be Python"?
(Also: waf: unconfigurable horror.)
libgit2 - a git library Posted Dec 2, 2010 16:24 UTC (Thu) by johill (subscriber, #25196) [Link]
Hmm, it claims to be faster than any other git *library*, but how about git itself?
libgit2 - a git library Posted Dec 2, 2010 19:27 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Sounds a bit pointless... better work with upstream to stabilize the API (won't be easy, git is still quite young) and build it as a shared library regardless. Oh well, it's not my call. Good luck!
libgit2 - a git library Posted Dec 2, 2010 22:29 UTC (Thu) by bronson (subscriber, #4806) [Link]
Why is it pointless? Many programs need to interact with git repos, and it truly sucks to do it via forking and piping git commands.
As far as I can see, this is a huge step forward. Love to see it.
libgit2 - a git library Posted Dec 5, 2010 17:36 UTC (Sun) by nix (subscriber, #2304) [Link]
I'm trying to figure out your objection to interacting with git repos via fork-and-pipe. Most interaction with git is disk-bound, so speed cannot be the problem. If it's just the verbosity, then the thing to do is surely to wrap up the fork-and-pipe stuff in a nice library, not *reimplement* it all in a library!
libgit2 - a git library Posted Dec 5, 2010 20:31 UTC (Sun) by Legile (guest, #71687) [Link] Accessing git data without forking, or without having to read an entire file to memory, should prove useful at least to my git fuse filesystem project. Git has a lot of potential as a data store (see projects like bup), and a library is just more robust and flexible for this class of applications.
libgit2 - a git library Posted Dec 13, 2010 20:37 UTC (Mon) by nix (subscriber, #2304) [Link]
Ah, true. That is one class of application where a library is useful: an application where vast numbers of requests may plausibly be made of the underlying git layer.
libgit2 - a git library Posted Dec 17, 2010 21:54 UTC (Fri) by dpotapov (guest, #46495) [Link]
Unfortunately, it is far more difficult to create a git library from the upstream source code than just stabilizing the existing API. One problem is that many git functions (if not most) can call die() directly or indirectly. This is done to simplify error handling -- the callee does not have to check for errors, also there is no need to worry about freeing all resources (memory, open files, etc), as they are freed automatically when the process exits. However, using die() makes git source code inappropriate for a library. Another issue is that git has a fair amount of variables that are initialized statically or memory that is never freed, because it can be allocated only once per run. Finally, most git source code is not re-entrant (though git may use multiple threads in a few cases such as creating packs).
On the other hand, libgit2 cannot replace git itself by any stretch of imagination, because it provides less functionality than git had after first two months of development. But if libgit2 functionality is enough for your application, and you don't want to pay the price of process creation then libgit2 may be the right choice.
|
|||||||||||||