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

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Oct 7, 2025, 17:21 UTC
Message-ID: <875xcq4oha.fsf@collabora.com>
In-Reply-To: <xmqqldlmlm1n.fsf@gitster.g>

On Tue, 07 Oct 2025, Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

> Adrian Ratiu <adrian.ratiu@collabora.com> 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.

Ack. I'll follow this design path in v4.

I was actually preparing to do the opposite :) i.e. drop the "override" and do the migration, thanks for clarifying before I did a re-roll. :)

Will leave this a week or two on the ML in case others want to review or have more feedback.

Show 10 quoted lines

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

Yes, though I don't think this is a big concern because submodule.c already has the validate_submodule_git_dir() check which prevents users from creating overlapping / nested dirs.

When the rare, deliberate clash does happen (like with .git/reftable) it can be treated like before: do nothing, let the user fix the repo, or we could add a small one-time migration at that point in time.

I really like avoiding any kind of automated blanket migration btw, thank you so much for your feedback Junio, it's really appreciated.