On 07/12, Jeff King wrote: > On Tue, Jul 11, 2017 at 03:04:05PM -0700, Brandon Williams wrote: > > > This series utilizes the new 'struct repository' in order to convert grep to be > > able to recurse into submodules in-process much like how ls-files was converted > > to recuse in-process. The result is a much smaller code footprint due to not > > needing to compile an argv array of options to be used when launched a process > > for operating on a submodule. > > 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. -- Brandon Williams
