From: Patrick Steinhardt Date: Tue, 09 Sep 2025 07:40:27 GMT Subject: Re: [PATCH v2 02/10] submodule: create new gitdirs under submodules path Message-ID: In-Reply-To: <20250908140117.262205-3-adrian.ratiu@collabora.com> On Mon, Sep 08, 2025 at 05:01:09PM +0300, 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. One of the questions here is how this move will affect alternate implementations of Git, like libgit2, JGit or Gitoxide. There's two angles to this: - Git needs to handle that those implementations continue to write submodules into ".git/modules". - These implementations need to be able to handle the new-style paths. The first item should work just fine, as we make sure that we handle both paths. But do the other implementations need any adjustment? I guess the answer is "yes", so we need to treat this as a backwards incompatible change as they wouldn't be able to find the submodule repositories anymore, right? Ideally, the way that submodules were populated was less fragile. For example, we could have a "submodule.*.repoPath" config key that gets populated whenever we clone a submodule. If Git clients knew to use that field they wouldn't have to second-guess where a previous Git client stored a specific submodule, but they could just read that path and then use whatever is stored therein. This would even allow for changes like using a hash to encode the submodule name. But to the best of my knowledge such a key does not currently exist, which is too bad (please correct me if I'm wrong, I'm definitely not an expert when it comes to submodules). Patrick