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

From: Patrick Steinhardt <[email-masked]>
Date: Sat, 6 Dec 2025 12:59:24 +0100

On Sat, Dec 06, 2025 at 07:47:56AM +0900, Junio C Hamano wrote:
> Adrian Ratiu <[email-masked]> writes:
> 
> >> It feels somewhat fragile to me that we unconditionally handle these
> >> cases and try to find old submodule directories. If the extension is
> >> enabled I'd expect that the submodule configuration is the _only_ source
> >> of truth.
> >>
> >> May I propose that we instead always error out in case the submodule
> >> configuration does not exist? In the best case we'd then give the user a
> >> nice error message that tells them how to run the migration manually.
> >
> > Junio told me to not do any kind of manual migration and just attempt
> > new names until one works and then use it consistently.
> 
> Indeed, but I do not think that has much relevance to Patrick's
> comment.  What I meant say was
> 
>  - With extension, we know that the repository will use the
>    configuration item as the sole source of truth.  Unlike the "we
>    now store submodule dirs to munged paths" design that we saw long
>    ago, which would have required us to sometimes move the existing
>    directories to match the munging scheme, we do not have to
>    manually migrate the existing directories.  Instead, we can just
>    record the pathnames they already use.
> 
>  - And with extension, when we add a new submodule, we would need to
>    give them an entry in the configuration that does not conflict
>    with those used by the existing submodules.  As Patrick mentions,
>    this name does not have to be done with any reversible mapping,
>    and third-party software and Git reimplementations can always
>    refer to the configuration to learn the path without knowing how
>    the path is chosen themselves.
> 
>  - The above two would ensure that the configuration would always
>    exist once a submodule enters our system (and "git submodule init"
>    is done to cause its gitdir created).
> 
> So, unless I am missing some corner case that still exists while
> bootstrapping a new style repository with extension, Patrick's
> "error when configuration is missing" sounds quite sensible to me.
> 
> I am officially still on vacation, so I'd stop here for now ;-).

I guess the one edge case is when somebody manually turns on the
extension after they have already initialized submodules. In that case
the gitdir paths would of course not exist in the gitconfig. But I think
blindly falling back to a source of truth different than the
configuration is wrong, as it would mean that the we have "a single
source of truth unless we don't". It would kind of defeat the whole
purpose of the extension in my opinion, as implementations cannot rely
on it.

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.

Patrick