Re: [PATCH 2/2] Move sequencer to builtin

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.