On Sat, Jun 8, 2013 at 8:34 PM, Ramkumar Ramachandra <artagnon@xxxxxxxxx> wrote: > I'm not saying that we can convert libgit.a into something that's > usable as a long-running process by production servers tomorrow. All > I'm saying is that it might be possible to get ruby (and possibly > other languages) to call into git-core, to make scripting more sane > than shell-spawning everything like brutes. I think this is what fc > is aiming at, atleast in the foreseeable future. It's technically possible. You can already call into libgit.a as fc demonstrated with his ruby binding. Assuming that you are willing to dig in and fix all the problems (in a non-intrusive way) when a call into libgit.a does not work, there's still API issue. Do we want to freeze libgit.a API so that scripts will not be audited and changed unncessarily? Freezing the API at cmd_* level loses a lot of flexibility. Freezing at lower level may prevent us from making some changes. I still think that binding new languages to a clean library like libgit2 is better than to libgit.a. Just thinking of what might work and what might not is already a headache. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html