From: Adrian Ratiu Date: Mon, 08 Sep 2025 15:46:46 GMT Subject: Re: [PATCH 2/9] submodule: create new gitdirs under submodules path Message-ID: <877by9ndzt.fsf@ratioveremundo.com> In-Reply-To: On Mon, 08 Sep 2025, Phillip Wood 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/, 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.