On Sat, Jun 8, 2013 at 7:55 PM, Ramkumar Ramachandra <artag...@gmail.com> wrote: > Duy Nguyen wrote: >>> until libgit.a == libgit2. Done. >> >> Read up about the introduction of libgit2, why it was created in the >> first place instead of moving a few files around renaming libgit.a to >> libgit2.a. Unless you have a different definition of "==" than I do. > > As far as I know, there was never an extensive on-list discussion > about why git.git cannot be lib'ified. The first appearance of > libgit2 is here [1]. I briefly read through the initial history of > libgit2.git too, but I cannot find a single discussion detailing why > lib'ifying git.git is fundamentally unworkable (there's some vague > mention of "global state baggage" and "presence of die()", but that's > about it). Unless you can point to some detailed discussions, or > write out a really good reason yourself, I don't think there's any > harm in letting fc try. Ofcourse, he still indicated any sort of plan > yet, and I'm also waiting for that. > > [1]: http://thread.gmane.org/gmane.comp.version-control.git/99608
Hm.. I thought Shawn wrote a bit more in that mail. Apparently I was wrong. I think it's discuessed in the list from time to time (otherwise I wouldn't know) but I don't keep bookmarks. I _think_ the reason is because git was never written as a reusable library in mind from the beginning. 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. 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. -- Duy -- 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
