Vadim Zeitlin <vadim@xxxxxxxxxxxx> writes: > JCH> Sounds reasonable, but I wonder how this would interact with > JCH> bootstrapping. Should it be configured in ~/.gitconfig, possibly > JCH> with [includeIf] to specify the directory you'd store a bunch of > JCH> repositories you clone from outside, or something? I guess "git > JCH> clone" without "--recurse-submodules" is simple enough to be used > JCH> for bootstrapping, and then the configuration can be set at the > JCH> top-level superproject after cloning but before "submodule init". > > I might be missing something here, but if the question is about whether we > need to have any special support for this in git-clone itself, then I don't > think so, it's a rather special use case and running git-clone without > --recurse-submodules and initializing (some) submodules later while > symlinking some other ones is only a minor inconvenience, if that. If you say so then I'd stop worrying about it ;-) I am not a heavy submodule user myself. The worry came primarily from the fact that this was reported as a "we have been using submodules happily in this particular manner but with a new version of Git it stopped working" regression. Your set-up was created with an older version of Git that did not have the problematic "defence in depth". If you or somebody else wanted to recreate the same set-up from scratch, would "git clone" that is unmodified, other than conditionally disables the check introduced by the commit e8d06089 (submodule: require the submodule path to contain directories only, 2024-03-26), let you do so? Or would it also need to honor the new configuration that conditionally disables the check, and if so, how would we make sure it is read during "git clone" (which has kind of special chicken-and-egg problem with respect to configuration settings). > ... Should it be something like > submodule.validate instead, perhaps? Please let me know if anybody has any > better ideas. Is "it MUST NOT BE a symbolic link" the only thing the validation does? Would there be extra check on top of what is currently there that may turn out to be useful? If the answers are no and/or yes, "submodule.validate=no" sounds like a reasonable choice, but I am not good at naming, so we may want to hear ideas from others. Thanks.
