Subject: Re: [PATCH v2 03/10] submodule: add gitdir path config override

From: Patrick Steinhardt <[email-masked]>
Date: Tue, 9 Sep 2025 09:40:32 +0200

On Mon, Sep 08, 2025 at 05:01:10PM +0300, Adrian Ratiu wrote:
> This adds an ability to override gitdir paths via config files
> (not .gitmodules), such that any encoding scheme can be changed
> and JGit & co don't need to exactly match the default encoding.
> 
> A new test and a helper are added. The helper will be used by
> further tests exercising gitdir paths & encodings.

Aha, so you already do what I'm lamenting about in the preceding commit.
It still raises the question around how to handle this whole migration
now, as alternative implementations don't yet know about this specific
config key. Doing all of this in a single patch series will most likely
result in breakage.

In theory, we should probably first introduce the configuration, then
wait a couple releases for alternative implementations to catch up, and
then switch over. But we still cannot be sure that implementations know
to handle this key alright.

A heavy-handed solution to this would be to introduce a repository
extension. This would ensure that any well-behaved Git client will
refuse to open the repository if it doesn't know about that specific
extension. With the remaining ones we can be sure that they know to
handle the "submodule.*.gitdir" configuration.

As mentioned, extensions are rather heavy-handed. Furthermore, this
whole infra is only really needed under very specific circumstances. So
maybe it could be a viable approach to make this extension opt-in:

  - We provide a new configuration "init.useSubmoduleGitdirExtension"
    that tells git-init(1) and git-clone(1) to use the new extension for
    newly initialized repositories.

  - We detect the situation where a submodule cannot be cloned due to a
    path conflict. If detected, we print a user-facing hint that tells
    them to enable the extension.

Once the user enabled the extension we'll know to use new, encoded
submodule paths from thereon and thus re-initializing the conflicting
submodule should work now.

With all of this I wonder whether we even need a new ".git/submodules"
directory. Couldn't we just continue to create submodules in the old
path and for example create a random suffix as required?

In any case, please stop me if I'm going overboard with my backwards
compatibility concerns :)

Patrick