On 05/22, Jeff King wrote: > On Thu, May 18, 2017 at 04:21:11PM -0700, Brandon Williams wrote: > > > When I first started working on the git project I found it very difficult to > > understand parts of the code base because of the inherently global nature of > > our code. It also made working on submodules very difficult. Since we can > > only open up a single repository per process, you need to launch a child > > process in order to process a submodule. But you also need to be able to > > communicate other stateful information to the children processes so that the > > submodules know how best to format their output or match against a > > pathspec...it ends up feeling like layering on hack after hack. What I would > > really like to do, is to have the ability to have a repository object so that I > > can open a submodule in-process. > > We could always buy in fully to the multi-process model and just > implement a generic RPC protocol between the parent and submodule gits. > Does CORBA still exist? > > (No, I am not serious about any of that). > > > This is still very much in a WIP state, though it does pass all tests. What > > I'm hoping for here is to get a discussion started about the feasibility of a > > change like this and hopefully to get the ball rolling. Is this a direction we > > want to move in? Is it worth the pain? > > I think the really painful part is going to be all of the system calls > that rely on global state provided by the OS. Like, say, every > filesystem call that expects to find working tree files without > prepending the working tree path. Yeah that's going to be one of the more challenging things to deal with... > > 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. Glad you think so! -- Brandon Williams