Re: [PATCH 2/9] submodule: create new gitdirs under submodules path
- From
Adrian Ratiu <adrian.ratiu@collabora.com>
- Date
- Sep 8, 2025, 15:46 UTC
- Message-ID
- <877by9ndzt.fsf@ratioveremundo.com>
- In-Reply-To
- <fc69ee66-815f-48ec-a5fb-99cac5f4d58c@gmail.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.
Show 20 quoted lines
> 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.