On Wed, 08 Jan 2025 08:03:42 -0800 Junio C Hamano <gitster@xxxxxxxxx> wrote: JCH> Vadim Zeitlin <vadim@xxxxxxxxxxxx> writes: JCH> JCH> > JCH> Sounds reasonable, but I wonder how this would interact with JCH> > JCH> bootstrapping. Should it be configured in ~/.gitconfig, possibly JCH> > JCH> with [includeIf] to specify the directory you'd store a bunch of JCH> > JCH> repositories you clone from outside, or something? I guess "git JCH> > JCH> clone" without "--recurse-submodules" is simple enough to be used JCH> > JCH> for bootstrapping, and then the configuration can be set at the JCH> > JCH> top-level superproject after cloning but before "submodule init". JCH> > JCH> > I might be missing something here, but if the question is about whether we JCH> > need to have any special support for this in git-clone itself, then I don't JCH> > think so, it's a rather special use case and running git-clone without JCH> > --recurse-submodules and initializing (some) submodules later while JCH> > symlinking some other ones is only a minor inconvenience, if that. JCH> JCH> If you say so then I'd stop worrying about it ;-) I am not a heavy JCH> submodule user myself. Well, let's just say that I'm not worried about it. JCH> The worry came primarily from the fact that this was reported as a JCH> "we have been using submodules happily in this particular manner but JCH> with a new version of Git it stopped working" regression. Your JCH> set-up was created with an older version of Git that did not have JCH> the problematic "defence in depth". If you or somebody else wanted JCH> to recreate the same set-up from scratch, would "git clone" that is JCH> unmodified, other than conditionally disables the check introduced JCH> by the commit e8d06089 (submodule: require the submodule path to JCH> contain directories only, 2024-03-26), let you do so? Or would it JCH> also need to honor the new configuration that conditionally disables JCH> the check, and if so, how would we make sure it is read during "git JCH> clone" (which has kind of special chicken-and-egg problem with JCH> respect to configuration settings). As I was trying to say above, I think it's unreasonable to expect "git clone --recurse-submodules" to do something extra smart when there is a simple (both to use and to discover) alternative of just running "git clone" without any extra options, and then initialize the submodules that you don't want to symlink manually and symlink the remaining ones. JCH> > ... Should it be something like submodule.validate instead, perhaps? JCH> > Please let me know if anybody has any better ideas. JCH> JCH> Is "it MUST NOT BE a symbolic link" the only thing the validation JCH> does? Currently, yes. JCH> Would there be extra check on top of what is currently there JCH> that may turn out to be useful? It's conceivable that there might be other checks in the future, e.g. maybe the ownership of the directories or even their permissions might be checked? Just to be clear, this is pure speculation on my part, i.e. I don't see any real need to do it, but I can't be certain that there are no scenarios in which this might be useful. JCH> If the answers are no and/or yes, "submodule.validate=no" sounds like JCH> a reasonable choice, but I am not good at naming, so we may want to JCH> hear ideas from others. I'll wait for some time to hear if anybody else has any better suggestions. Thanks in advance! VZ
Attachment:
pgpp4gff97PUz.pgp
Description: PGP signature
