"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > Since this is a defense-in-depth change and it seems to have broken a > reasonable workflow, I think adding a config option for this would be > reasonable. We've recently had some discussions on trying to limit the > defense-in-depth measures we implement on the security list in the > interests of allowing better discussion and feedback on the main list > and avoiding regressions in people's workflows, and I think your email > lends support to that approach. Thanks; I was writing my own response and said pretty much the same thing as above, before I saw this message. > I'm not presently planning to add such an option, but it shouldn't be > too hard to add a global variable for that (or maybe something under > struct repository) that's updated when parsing config, and then check it > in `validate_submodule_path`. We'd need docs for that option as well, > but that would probably be it if someone wanted to do so. Sounds reasonable, but I wonder how this would interact with bootstrapping. Should it be configured in ~/.gitconfig, possibly with [includeIf] to specify the directory you'd store a bunch of repositories you clone from outside, or something? I guess "git clone" without "--recurse-submodules" is simple enough to be used for bootstrapping, and then the configuration can be set at the top-level superproject after cloning but before "submodule init".