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

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 9, 2025, 07:40 UTC
Message-ID: <aL_Z8DusXdyIr4Ru@pks.im>
In-Reply-To: <20250908140117.262205-4-adrian.ratiu@collabora.com>

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

Show 6 quoted lines

> 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