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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html