Re[2]: Would it be possible to add an option to disable validating submodule paths?

On Tue, 07 Jan 2025 15:25:28 -0800 Junio C Hamano <gitster@pobox.com> wrote:

JCH> "brian m. carlson" <sandals@crustytoothpaste.net> 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