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

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Sep 9, 2025, 17:46 UTC
Message-ID: <87bjnj7c3y.fsf@collabora.com>
In-Reply-To: <aL_Z8DusXdyIr4Ru@pks.im>

On Tue, 09 Sep 2025, Patrick Steinhardt <ps@pks.im> wrote:

Show 9 quoted lines

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

Not quite. I tried to explain in my previous reply that this only looks similar and perhaps I should have worded the commit message differently (I promised Phillip I'll reword it), however it's intended just to allow simple overrides, without being a unified way for all implementations to work with gitdirs. :)

Show 9 quoted lines

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

Exactly, they won't. :)

Show 22 quoted lines

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

This is actually a very good idea, to detect path conflicts and print a nice message to instruct the user to enable the extension, instead of the default "error: git dir is inside git dir" or somesuch confusing msg.

I'll work on it for patch v3 and add some tests.

Show 9 quoted lines

> 
> 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?

Now that we decided to put this logic behind an extension, we might get away with having a unified directory, yes. It's something I'll explore for v3. I would really like to avoid having both "modules" and "submodules" alongside eachother.

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

You have good ideas and your feedback is much appreciated. Kudos and thanks!