Subject: Re: [PATCH v5 4/7] submodule: add extension to encode gitdir paths

From: Adrian Ratiu <[email-masked]>
Date: Mon, 08 Dec 2025 11:01:33 +0200

On Sun, 07 Dec 2025, Junio C Hamano <[email-masked]> wrote:
> Patrick Steinhardt <[email-masked]> writes:
>
>> Maybe the right approach would be to tell users to never manually enable
>> the extension and instead to provide a command that both:
>>
>>   - Persists the submodule gitdirs for any populated submodules in the
>>     gitconfig.
>>
>>   - Enables the repsitory extension.
>>
>> If we had that then we could count on the submodule gitdirs to exist in
>> the gitconfig, and if they don't we would die with an error message that
>> indicates that the repository is broken, maybe even with a hint for the
>> user on how to fix it.
>
> I personally like the simplicity of this approach.
>
> I haven't however thought about operational complexity, if one has
> an existing user base that have been using a custom pathname munging
> code that needs to be migrated to the new scheme.

The good news is that for all the real-world use cases I'm aware of,
migration to the new scheme should just work.

The problem we're discussing here (automatic fallback vs requiring the
gitdir to always exist + using a migration tool) does add a bit of
operational complexity, however it might be manageable.

I have to see how this works in practice, especially with the users
setting the config (likely I'll add an error to block that path) and the
build-config to enable the extension by default (will likely run the
migration tool automatically on existing repositories if enabled via the
build-config).

I will attempt this approach in v6.