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

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Dec 8, 2025, 09:01 UTC
Message-ID: <87tsy1uz2q.fsf@collabora.com>
In-Reply-To: <xmqq8qffpnui.fsf@gitster.g>

On Sun, 07 Dec 2025, Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

> Patrick Steinhardt <ps@pks.im> 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.