On Wed, Jul 12, 2017 at 11:06:03AM -0700, Brandon Williams wrote: > > I didn't follow the rest of the "struct repository" series closely, but > > I don't feel like we ever reached a resolution on how config would be > > handled. I notice that the in-process "ls-files" behaves differently > > than the old one when config differs between the submodule and the > > parent repository. As we convert more commands (that use more config) > > this will become more likely to be noticed by somebody. > > > > Do we have a plan for dealing with this? Is our solution just "recursed > > operations always respect the parent config, deal with it"? > > Each 'struct repository' does have its own config so we could > potentially want a config in a submodule to override some config in the > superproject. Though for right now it may be simpler to not worry about > doing this overriding, mostly because you would only want to allow > overriding of some configuration and not all configuration. One example > would be the number of threads allowed in grep, it doesn't make much > sense to let a submodule's configuration of this to trump the > superproject's since the command was invoked in the context of the > superproject. I'm not sure I agree 100% with that example. What makes threads special, I think, is not the config but the total count spread across all of the recursive processes. So it's not that we don't want to respect submodule config so much as we want to take the submodule config into account, but throttle it based on what other threads are running. So if your superproject says "1" and the submodule says "8", I'd expect "8" threads to run in the submodule. If you're already running another 3 threads on behalf of another submodule, I think it would be reasonable to do some job control and only give the submodule 5 slots. But I don't think that should happen at the config layer. It should probably happen when the submodule decides to spawn threads, and it should ask of the superproject "how many slots am I allowed?". I think that's probably one of the more complicated cases, and I don't think it really needs to be done on day one. Setting differing thread counts is even more unlikely than the rest of the config. I suspect doing job management in general would come up first, because people don't want to fork-bomb themselves. Anyway, that got pretty far afield. What I was trying to say is that I think you can treat the config uniformly, without making special exceptions for things like grep.threads. -Peff
