On Tue, 07 Jan 2025 15:25:28 -0800 Junio C Hamano [off-list ref] wrote:

JCH> "brian m. carlson" [off-list ref] writes:
JCH> 
JCH> > Since this is a defense-in-depth change and it seems to have broken a
JCH> > reasonable workflow, I think adding a config option for this would be
JCH> > reasonable.  We've recently had some discussions on trying to limit the
JCH> > defense-in-depth measures we implement on the security list in the
JCH> > interests of allowing better discussion and feedback on the main list
JCH> > and avoiding regressions in people's workflows, and I think your email
JCH> > lends support to that approach.
JCH> 
JCH> Thanks; I was writing my own response and said pretty much the same
JCH> thing as above, before I saw this message.

 Thanks to both of you for your replies, I'll try to come up with a patch
relatively soon.

JCH> > I'm not presently planning to add such an option, but it shouldn't be
JCH> > too hard to add a global variable for that (or maybe something under
JCH> > struct repository) that's updated when parsing config, and then check it
JCH> > in `validate_submodule_path`.  We'd need docs for that option as well,
JCH> > but that would probably be it if someone wanted to do so.
JCH> 
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.

 OTOH I've realized that I have no idea how the new option should be
called. I had initially thought about "safe.submodules = bool", but I'm not
sure if this is really consistent with the existing safe.xxx options which
look and behave a bit differently. Should it be something like
submodule.validate instead, perhaps? Please let me know if anybody has any
better ideas.

 Thanks,
VZ