On Sat, Jun 8, 2013 at 8:34 PM, Ramkumar Ramachandra <artag...@gmail.com> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to