Duy Nguyen wrote:
> I _think_ the reason is because git was never written as a reusable
> library in mind from the beginning.

We cannot reverse-engineer intents, but I tend to agree with this.  My
question is: so what?  Is it impossible to do now?

> So global states and die() exist.
> Worse, "run once and let the OS clean eveything up at process exit"
> leads to some deliberate memory leak if it's made a library. See
> alloc.c for example. The internal API is not really designed to be
> usuable/stable as a library. All of these made it very hard to convert
> the current code base into a true library. So the effort was put into
> creating a new library instead, copying code from git code base over
> when possible.

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.

As far as long-running server-side implementations go, I think jgit is
the way forward (sop is more interested in that now, I believe).
libgit2 might work for GitHub now, but I don't know if they will be
forced to move to the jvm in the future.

> So instead of redoing it again, I think it's better that you help
> libgit2 guys improve it to the extend that git commands can be easily
> reimplemented. Then bring up the discussion about using libgit2 in C
> Git again.

Please look at the code in libgit2.git briefly.  It's _very_ different
from git.git, and the amount of glue code that would be needed to
piece them together is unfathomable.

There are no git.git contributors committing to libgit2.git, or
vice-versa.  libgit2 is primarily developed by vmg, cmn, and (more
recently) rb.  It's quite an active project that's diverging from the
git.git design with every passing day.
--
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