From: Adrian Ratiu Date: Tue, 09 Sep 2025 10:57:43 GMT Subject: Re: [PATCH 2/9] submodule: create new gitdirs under submodules path Message-ID: <87jz277v14.fsf@gentoo.mail-host-address-is-not-set> In-Reply-To: <5290c591-fd3d-4737-bfcb-fc091751af1a@gmail.com> On Tue, 09 Sep 2025, Phillip Wood wrote: > Hi Adrian > > On 08/09/2025 16:46, Adrian Ratiu wrote: >> On Mon, 08 Sep 2025, Phillip Wood >> wrote: >>> >>> Does this need an extentions.submoduleEncoding (name >>> suggestions welcome) config key to stop older versions of git >>> trying to read the repository as they wont be able to locate >>> the gitdir of any submodules  added under .git/submodules? >> Very good point. I'm a bit unsure we actually need it, likely >> we do. On the one hand, older versions of git can still >> initialize and work on submodules under the legacy >> .git/modules/ path ignoring the new one... On the other hand, >> there is a non-zero risk users will get in trouble by >> switching git versions or can lead to inconsistent/corrupted >> states, so I'm inclined to say the answer is yes: better safe >> than sorry. > > If we only needed to convert the submodule name to a gitdir when > the submodule was initialized and all other access went through > the .git file of the submodule in the working tree then I think > old clients would be fine because they'd find the right gitdir > by reading the .git file. I'm not familiar with the submodule > code but I don't think that's the case in which case I agree it > would be safer to add an "extestions" config key. Yes, your understanding is correct and it goes beyond just the git core (where we at least have a unified API to compute the gitdir path, so making the subsequent accesses follow .git file contents would be easy), it also affects JGit, libgit2 and other implementations, so it's the most prudent approach to put this behind an extension key.