Re: [WIP/RFC 00/23] repository object

From: Duy Nguyen <pclouds@gmail.com>
Date: May 29, 2017, 11:31 UTC
Message-ID: <CACsJy8AtMNAE=5jihV+sYZqyx40JCJ0hkZAvqFbkOU1g5sZSYA@mail.gmail.com>
In-Reply-To: <CACBZZX5GRxecDQkoqLv55FLuiSohGSR3U1U+sG0vFFpexcc54A@mail.gmail.com>

On Mon, May 29, 2017 at 6:23 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 14 quoted lines

>>> That said, even if we never reached the point where we could handle all
>>> submodule requests in-process, I think sticking the repo-related global
>>> state in a struct certainly could not hurt general readability. So it's
>>> a good direction regardless of whether we take it all the way.
>>
>> I doubt we would reach the point where libgit.a can handle all
>> submodule operations in-process either. That would put libgit.a in a
>> direct competitor position with libgit2.
>
> Wouldn't that be a good thing? We already have some users (e.g.
> Microsoft) choosing not to use libgit and instead use git.git because
> the latter is generally more mature, if git.git gains more libgit
> features without harming other things it'll be more useful to more
> people.

Whether it's a good thing might depend on view point. Similar to linux kernel, we might want some freedom to break ABI and refactor the code. But I think it's too early to discuss this right now. There's lots of work (the "die()" minefield comes to mind) before we reach the point where libgit.a may be good enough for external use.

-- 
Duy