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

[Duy Nguyen <pclouds@gmail.com>]

On Sat, Jun 8, 2013 at 7:55 PM, Ramkumar Ramachandra <artagnon@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