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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 7, 2025, 16:21 UTC
Message-ID: <xmqqldlmlm1n.fsf@gitster.g>
In-Reply-To: <87frbv3qyr.fsf@collabora.com>

Adrian Ratiu <adrian.ratiu@collabora.com> writes:

Show 13 quoted lines

>> 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.