Re: [PATCH v2 02/10] submodule: create new gitdirs under submodules path

[Patrick Steinhardt <ps@pks.im>]

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/<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.

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