Subject: Re: [PATCH v3 0/5] Encode submodule gitdir names to avoid conflicts

From: Junio C Hamano <[email-masked]>
Date: Tue, 07 Oct 2025 09:21:56 -0700

Adrian Ratiu <[email-masked]> writes:

>> If you already have submodules creted under the original scheme, 
>> then add a new submodule that needs this extension, do you 
>> enable this new extension and write the new submodule under 
>> encoded name, and move the existing submodules under their 
>> encoded names? 
> ...
> We could do a migration of existing gitdirs to the new encoding to 
> ensure consistency when the extension is enabled.
>
> This will simplify our logic and assumptions a lot, at the cost of 
> the initial up-front migration.
>
> Will do this in v4 if nobody has any objections.

Let's not.

You have support for submodule.<name>.gitdirpath already, so it is
far safer to use that mechanism to etch-in-stone-fix the existing
submodules and their gitdirs without touching the directories for
migration.

One case you might want to really move directories when migrating is
when two existing submodules' gitdirs are already overlapping, e.g.,
.git/modules/A and .git/modules/A/B are used for submodule A and
submodule A/B.  Depending on what "B" is, a project with such a
layout may not be able to upgrade to versions of Git that newly
starts using .git/B directory for a new feature.  Introduction of
a new directory or a new file directly underneath $GIT_DIR is rare
but does happen (.git/reftable/ is a relatively recent addition, for
example).

Thanks.