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

> On Sun, 07 Dec 2025, Junio C Hamano <gitster@pobox.com> wrote:
> > 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.