I went looking for a library interface to git tonight. (I can already hear some of you laughing.) Turns out that my assumption that there must be a nice git library out there somewhere might have been a bit .. naive.
Git itself makes an archive of the common files that it uses in its various C apps and links those into each app. In what can only be a fit of humor, it calls this thing a "library" in its Makefile.
Yes, more humor: a naked Makefile. After all, real mean don't use pansy tools that might make life easy like configure of cmake, right? Anyways .. I really didn't go looking for a build system, I went looking for a library I could use to interact with a git repository.
Why a library? Well, I really don't want to be running external commands and then parsing their output. Unfortunately that seems to be what most other apps that provide git fronts seem to be doing.
I got slightly excited when I saw the "Interfaces to other programming languages" on the Git wiki. I though, "Ok, so I won't be doing this in C++, that's ok .." only to find out that I could write in ObjectiveC (uuuuh..) or Java (mmmmm.. no.) Both fail for not having KDE4 bindings. Unfortunately both the Python and Ruby git thingamabobies are for read only access. After all, who wants to commit, anyways, right? *sigh* Dashed once again, I return to the idea of doing it in C++, but the specter of having to parse command line output just makes me cry.
A small spark of hope remains in me knowing that I am not intimately familiar with the world of git and therefore may be missing that wonderful bit of interface glory that I call "libgit.so" in my daydreams.
Why would one want such a thing? With a nice sane API to a nice flexible SCM we might actually see some cool integration into desktop applications to make user's lives easier.
So .. does anyone out there have a link to such a "libgit.so" type thing? If so, I promise to make something cool with it. =)
About Me
Labels
- akademy (3)
- amarok (1)
- appeal (1)
- build system (1)
- community (7)
- crash (2)
- d-bus (1)
- dataengine (1)
- dolphin (2)
- events (1)
- family (1)
- free software (1)
- gnome (2)
- graphics (1)
- guademy (1)
- kde (52)
- kde e.v. (3)
- kde; kdegraphics (1)
- konqueror (1)
- krunner (4)
- libs (5)
- lug radio (1)
- media center (1)
- misc (1)
- openid (1)
- oxygen (2)
- performance (1)
- photos (1)
- plasma (26)
- podcast (1)
- pr (1)
- prose (1)
- release (1)
- social (1)
- solaris (1)
- techbase (6)
- travel (6)
- trolltech (3)
- web2.0 (1)
26 comments:
Hi Aaron,
I suggest to take a look at Mercurial (HG) as an alternative. Nowadays Git and Mercurial are very close to each other in terms of functionality, internal datastructures and also performance.
Mercurial is fully written in Python but really has a serious API one can use to do commits, pulls, pushes (even to git repositories if I'm correct).
If I remember correctly it's very straight forward to use python code directly from C++ to interface with python code.
If you install Mercurial and execute 'pydoc' afterwards you can study the 'api' Mercurial provides.
Cheers and thanks for all the great things!
nielsvm
There is libgit2 effort headed by some of the core git people at http://repo.or.cz/w/libgit2.git
Unfortunately, this is far from finished, but it is slated to become the standard git library interface (even to be used by the main git executable).
They're working on it. :-/
libgit2 is the library that will have a stable API/ABI and be reusable in other projects/apps, and what you need to google for. One of the best hits, and in fact that place where I first heard of it, is the mailing list thread archived on kerneltrap at:
http://kerneltrap.org/mailarchive/git/2008/10/31/3880864
git was developed in a hurry. Linus needed something to do Linux development on after BK disappeared. Getting something working ASAP, while kind of designing it as you go along (although Linus' "hacking something crudely together" may well give better results than quite a lot of other people's careful design :) is not a process that tends to result in reusable shared libraries.
Hey, at least there's now an private library written in C - it could still just have been a collection of shell scripts!
It's probably not what you're looking for, but Bazaar has a very nice and very elegant library: http://starship.python.net/crew/mwh/bzrlibapi/
Maybe not the best way to do this, but git internally creates libgit.a and xdiff/lib.a . These are used by e.g. cgit web frontend.
One day it may turn into a real library, but for now...
Is it pure coincidence that planetKDE and planetGNOME both have git stories at the top of the page at the same time?
The decision has already been taken and all thsat, but while on the subject, there is a very nice comparison of DCVSs:
http://www.infoq.com/articles/dvcs-guide
Heh, make a C++ binding for the Java library through JNI :) (yes, I'm insane, thanks for asking)
In related news, KDevelop4 has Git support too. Maybe there's the possibility of your solution sharing code with KDevelop.
Aaron, check gitorious. It's a ruby frontend for git. For all the "read actions" you want to do, it has a ruby library to deal with git. For "write actions" it uses ssh ;).
But ok ok...I may know what you have in mind and ruby may not be the perfect language for this hehe...
Anyway, for C we have libgit2, but I think it's not stable yet...
Cheers ;)
I'm working on a libQtGit library which provides a Qt-like API to git.
So far, the API includes the following commands:
- add
- commit
- init
- mv
- rm
- checkout
- clone
- branch
- revert
- reset
- clean
- gc
- merge
- push
- fetch
- pull
- rebase
- config
At this moment, only a handful of them are actually implemented but I'm working on it.
The current implementation is a QProcess calling git. If libgit2 is ever finished, I will move to use it.
libQtGit will be open source (LGPLv2.1 and LGPLv3). I hope to release a first version by the end of January.
libgit2 is on the go but not close to be ready.
Speaking of python, there used to be "pygit" which has write access (I'm migrating my website so you'll have to wait it to come back or try this version http://pypi.python.org/pypi/pygit/0.1) which was done especially to allow writing new commits. I've been working at merging it into the gitpython thing lately...
Another alternative is dulwich ("a pure-Python implementation of the Git file formats and protocols.")
The mercurial has basically had this from day 1, yet everyone still seems to be along with the git bandwagon for what, that 0.3 seconds it saves on spitting out 10000 log messages? Who cares.
Company I work for uses an older fedora core, winxp, mac, etc and hg installed without a hitch on all. I can't say the same for git.
Git and Mercurial's approach to changes are very different. They're not comparable. Git and Bazaar are; however, IIRC.
@Pau: i'm very interested. let's find each other on irc!
@grok-mctanys: libgit2; thanks for the pointer. it is still fairly raw though. looking forward to it becoming usable. =)
@dholbach: yes, i'm not interested in bzr at all. thanks, though =)
@adamg: yeah, i looked at the .a file and cringed. not a friendly API, and for understandable historical reasons.
@Jakob Petsovits: hm. i'm going to look at that now =) thanks...
@MoRpHeUz: yes, the grit Ruby lib looks really nice but is read only. if it doesn't have write (and grit doesn't, i checked into grit before writing this post =) it's not much use to me. =/
@gpoo: dulwich; interesting i'll be checking that one out as well. thanks.
@Tom Burdick: "The mercurial has basically had this from day 1, yet everyone still seems to be along with the git bandwagon for what, that 0.3 seconds it saves on spitting out 10000 log messages? Who cares."
actually, it has nothing to do at all with speed for me. it has everything to do with two very simple facts: the community creating third party tools around git is insanely huge; the number of people who know and use git dwarf hg and bzr combined.
those two things alone make all the difference since the three aren't otherwise all that much different. it's a close race on technical issues with each having its strengths and weaknesses.
but git's army of users and 3rd party devs just can't be matched by the others. and for a tool that is supposed to be used for collaboration, which implies people involved, that's a rather important thing.
in fact, it's the only thing that makes me nervous about leaving svn for git for big projects like kde.
How about ruby?
http://rubyconf2008.confreaks.com/using-git-in-ruby-applications.html
Linus don't like C++.
http://thread.gmane.org/gmane.comp.version-control.git/576431/focus=57918
Is there no way of avoiding enforcing a choice of DVCS system on potential contributors. I've researched the main contenders and they all have pros and cons and no doubt all will improve and maybe a better one will come from nowhere in the future also. Can the repository not be set up which works for git/hg/bzr users agnostically?
Isn't that kind of what KDE was setup for? Not getting tied-in?
Speaking of the easy of CMake, where is libcmake?
It would be great if the kdevelop developers could write something like this:
CMakeProject project(projectdir);
QEntryInfoList includes = project.getIncludes(targetname, sourcefile);
QMap<QString, QString> macros = project.getExternalMacros(targetname, sourcefile);
CMake and qmake should really make libraries available. That's even more important than a git library.
@krusty: i looked at grit and it is mostly read only. it has basic commit possibilities, but very limited from what i can see.
@Borisov Sergey: "Linus don't like C++."
i'd be happy for a C library. that doesn't exist either.
Linus' like or dislike of any language doesn't really matter. this project he birthed has some obvious technical shortcomings like lack of code reuse or sane programming APIs.
@YhLCsWx8kpdRtGK5jc7hJiAV20VDF4su_xsfNDNlnPAz: "Is there no way of avoiding enforcing a choice of DVCS system on potential contributors"
a) what i'm working on has nothing to do with KDE using git.
b) when it comes to conbtributing, the most STUPID thing we could do is have multiple toolsets. it raises the barrier to entry, increases what one must learn and divides up development efforts into little islands.
"Isn't that kind of what KDE was setup for? Not getting tied-in?"
you're taking the licensing of the software and applying it to something that's completely different.
@Jos:
"CMake and qmake should really make libraries available."
agreed, particularly CMake since we rely on it ;)
"That's even more important than a git library."
not for what i'm doing. a CMake/qmake lib is irrelevant to this project, while a git lib is rather key to achieving precisely what i'm after. =)
so many assumptions get made, but that's cool because it means i'll surprise everyone (who isn't on plasma-devel, anyways ;) when i share what i'm working on. wee!
There is a Slashdot news, you can try to ask it there, too.
Git is the best SCM I ever used.
Hey Aaron, did the weekly KDE video news thingie die?
Ok, since no one bit, I'll bite:
WHAT exactly are you working on? :)
Post a Comment