On 05/29, Duy Nguyen wrote: > 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. My personal end goal is making the code easier to parse and to make submodule work easier. I know I've only worked on the project for a short time but I already regret some of the submodule changes that I've made because they are straight up hacks which I want to eradicate sooner rather than later (just look at my patches to get 'git grep' to handle submodules...). I wasn't thinking about libgit2 and don't really haven't thought too much about the possibility of being in competition with that project. -- Brandon Williams