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

> On Sat, Dec 06, 2025 at 07:47:56AM +0900, Junio C Hamano wrote:
>> Adrian Ratiu <adrian.ratiu@collabora.com> 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.