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

[Junio C Hamano <gitster@pobox.com>]

Vadim Zeitlin <vadim@zeitlins.org> 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.