Subject: Re: [PATCH 2/9] submodule: create new gitdirs under submodules path

From: Adrian Ratiu <[email-masked]>
Date: Tue, 09 Sep 2025 13:57:43 +0300

On Tue, 09 Sep 2025, Phillip Wood <[email-masked]> 
wrote:
> Hi Adrian 
> 
> On 08/09/2025 16:46, Adrian Ratiu wrote: 
>> On Mon, 08 Sep 2025, Phillip Wood <[email-masked]> 
>> 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.