Hi Patrick and thank you for the feedback! o/

On Tue, 09 Sep 2025, Patrick Steinhardt [off-list ref] wrote:

On Mon, Sep 08, 2025 at 05:01:09PM +0300, Adrian Ratiu wrote: 

quoted

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?

That is correct and also applies to older versions git itself 
which do not have this mechanism. Phillip Wood suggested we add an 
extension like "extensions.submoduleEncoding" (name suggestions 
welcome).

I'll do that in v3 of this series.
 

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.

Slight tangent (I'll respond to your point after this):

Junio asked to please keep the name human-readable and that's why 
we use url-encoding which is also widely known and well 
understood.

I guess we could add a config to change the name encoding or 
hashing mechanism while keeping url-encoding as the 
default. Likely in a later series because this one is big enough 
now at 10 patches and keeps growing. 

One of my Collabora collegues even suggested they would like to 
use a pattern like "hash_name" to get the best of both worlds.
 

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

No, it does not exist. I've added something a little bit similar 
with the gitdir path config option in this series, however it is 
only used to override default paths computed by git-submodule, 
when necessary. 

There is also a config clutter problem, if such a key were to be 
added by default, since most submodules use default paths.

Phillip had the idea to only compute the path once, during the 
initial submodule clone, then reuse it from the .git file inside 
the submodule workdir in later actions, however that is not enough 
for compatibility with other implementations or older versions.

So yes, to avoid user confusion, multi-implementation 
inter-operability problems or risk any repo inconsistency, I'll 
make it a breaking change.