On Mon, May 29, 2017 at 6:23 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: >>> 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