You probably have heard about git, the stupid content tracker. It is a distributed revision control system with an emphasis on speed and KDE is slowly migrating from Subversion to git.
One of the main problems of git is it is a fire-and-forget tool: run one command, exit. You cannot run two commands without re-initializing everything because it was never developed with that in mind. That poses a serious problem if you want to use a git repository from your application. It was not possible to split git in two, a library and an application-linking-to-the-library (I (trivially) tried that).
The typical solution to the problem was to develop a library which invokes git processes and use that library from your application. For something I wanted to do in KOffice (which I will post as a wish soon), I started to develop a similar library with a Qt-like API. I called it libQtGit and the latest source is available from gitorious.
The main reason I put development on hold was libgit2. At least three or four efforts were started to properly split git into library + application and one of those that looked very promising was started soon after I started libQtGit. At the time, waiting for this (in the beginnings) quickly-progressing libgit2 looked like a good idea (lesson learned: use what you have NOW, not what you will have in a few months – as you may never get what you are waiting for). As I was saying, that libgit2 try never made much progress, and in the meanwhile I started working on other stuff.
These days the situation is very different: Vicent Martí started a libgit2 for his Summer of Code 2010 and his achievement was excellent.
So here is my wish: implement libQtGit using libgit2 instead of QProcess(“git”).
https://projects.kde.org/projects/playground/libs/libqgit2
@Eike:
Man, I swear I’ve had this “a wish a day” cooking for months!
Very interesting and nice, anyway 🙂
@Eike:
I’ve looked at the libqgit2 source and it’s much much lower-level than my libQtGit.
In fact, libqgit2 is (at least for now) only kind of a let’s put methods in classes: git_commit_lookup(…) -> Git::Commit::lookup(…), git_index_entry(…) -> Git::Index::entry(…), etc.
I was aiming for something higher level, which would be easier to use. I would say the difference between my idea for libQtGit and the current libqgit2 is:
– With libqgit2 you can a) implement git using Qt, b) make an application that uses a git repository (but you’ll need to deal with a lot of low level stuff)
– With libQtGit you can make an application that uses a git repository. It doesn’t try to implement git in Qt.
I’d say wait some more. There is another code of summer coming up, which includes improvements to libgit2. If that project is picked up, and succeeds, it will be much easier to build the libqtgit2 or whatever.
Higher-level functions can be added to libqgit2. I am not against it and keeping the current low-level availability, too. It is just the freedom so that to provide them the low-level way as well.
On the other hand the other language bindings are also implemented that way as I started, thus I am not entirely sure why to break that interface.
Unfortunately, I do not have too much time for this project right now because of my Gluon dedication, but let us see.
What I see from this is that, if I am not mistaken, you can improve libqgit2 with your high-level methods, classes etc or provide your library which supports only the high-level way. (I prefer the first, but it is your turn (: )
Ohh sorry, my fault, I did not check the codebase out.
As it seems it heavily uses the QProcess which is not a preferred in my opinion. That is why the whole libgit2 access library project has been started.
Basically this is QProcess-like way and output parsing is implemented at more places, like KDevelop and VCS integration, but it is really not the preferred way of doings things.
Unfortunately there was no git access library previously and that is why this libgit2 project is nice and I thought it might be worthwhile to provide a higher-level interface.
Esben Mose Hansen mentioned the upcoming GSoC which is the network related operations. It might be a very nifty improvement, thus libgit2 has good prospects.
@Laszlo
Replacing libQtGit’s use of QProcess with libgit2/libqgit2 is exactly the point of my post 🙂 I do not have spare time to do that, though.
“with an emphasis on speed ” – how long did svn up take for the whole i18n directory? Like 10 seconds? How long did git clone on a single project take? Well, I cancelled it because it took over 20 minutes.
i don’t see any advantage in use of libgit2 over calling git directly, because you won’t call git in loops anyway.
but disadvantages are:
1. been always behind reference git implementation
2. library will be always sit around in memory, even if use different VCS
3. and it’s definately not a unix-way with one function per application, that doing it well
@hate-engine
i don’t see any advantage in use of libgit2 over calling git directly,
Calling git directly means spawning a QProcess, which takes a lot of time. Sometimes starting and stopping the QProcess takes longer than the execution or the git command itself, not to speak of the nastiness of parsing the output of git.
because you won’t call git in loops anyway.
Yes, you will. Not exactly in loops but continued usage. See wish #2.
hate-engine:
QProcess is not a gentle option in my opinion (that is the whole thread about), you cannot ask \Output Compatibility\ there, lol 🙂 ( not speaking about the localization etc…)
Any output change can cause a havoc…