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

[Adrian Ratiu <adrian.ratiu@collabora.com>]

On Mon, 08 Sep 2025, Phillip Wood <phillip.wood123@gmail.com> 
wrote:
> Hi Adrian 
>

Hello Phillip and thanks for the feedback! :)

I just sent v2 at the same time if you want to give that a look, 
though the issues you raised are still valid for v2 as well.
 
> On 16/08/2025 22:36, Adrian Ratiu wrote: 
>> This is in preparation for encoding the submodule names to 
>> avoid conflicts like submodules named foo and foo/bar together 
>> with case-insensitive file- system handling and other corner 
>> cases like reserved filenames on Windows.   Backward 
>> compatibility is kept with plain-name modules already existing 
>> at paths like .git/modules/<name>, however a clear separation 
>> between legacy (plain) and new (encoded) namespaces is 
>> desirable, to avoid situations like an existing plain-name 
>> module containing the encoding escape character/  Thus we split 
>> the new-style (encoded) gitdir name paths to .git/submodules, 
>> while legacy-style paths remain under .git/modules.   This is 
>> just a default directory change with the accompanying test 
>> updates, in preparation for the actual encoding additions in 
>> future commits. 
> 
> 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.

So if there are no objections or better ideas, I'll add this in v3.