Hi Peff, On Mon, 13 Sep 2021, Jeff King wrote: > On Mon, Sep 13, 2021 at 01:37:48PM +0200, Johannes Schindelin wrote: > > > > Good point. So fspathcmp() and friends would need a repo parameter. :-| > > > > Yes, we will eventually have to pass `struct repository *r` into a _lot_ > > of call chains. It'll be a disruptive change, yet if the submodule folks > > truly want to aim for in-process recursive treatment of submodules, there > > is no alternative. > > > > FWIW on Windows there are other potentially repository-specific settings > > that are relevant in similar situations. For example, there is > > `core.symlinks`. > > Another approach is to stuff the appropriate globals into the repository > struct, and then "push" onto the global the_repository pointer, treating > it like a stack. And then low-level code is free to use that global > context, even if it wasn't passed in. > > That helps the primary use case of "now I need to do something in a > sub-module, but I'd like to do it in-process". But it's not without > challenges: > > - code which acts at the boundary of a submodule and a superproject > may be more awkward (since only one of them can be "the current > repository" at a time). > > - it's a challenge with threading (an obvious problem would be a > multi-threaded grep which wanted to descend into a submodule). Using > a thread-local global for the_repository might solve that. > > It's possible that this is a terrible direction to go, so I'm not > necessarily endorsing it, but just offering it as a possibility to think > about. The trickiest thing is that any devil would likely be in the > details, and we wouldn't know until proceeding for a while along that > path. Whereas passing around a context struct, while verbose and > annoying, is a well-understood construct. I would not so far as to call it a terrible direction. It is definitely worth a thought or two. At the end of the day, I fear that it is too tricky in practice, though. Seeing as there seems to be some appetite for refactoring Git's code on this list, I am thinking that the `struct repository *r` direction might be the one to go for. And I mean like "move the globals into that struct" as opposed to introducing that stack you talked about. It would even be a refactoring where I would understand the motivation, and agree with it, too. Ciao, Dscho
