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

From: Adrian Ratiu <[email-masked]>
Date: Tue, 07 Oct 2025 14:13:00 +0300

On Mon, 06 Oct 2025, Junio C Hamano <[email-masked]> wrote:
> Adrian Ratiu <[email-masked]> writes: 
> 
>> Hello everyone, 
>> 
>> v3 is much simplified from v2, starting from the design idea 
>> that submodule gitdir name encoding is to be put behind an 
>> extensions.submoduleEncoding. 
> 
> This design decision to make it an extension makes a repository 
> with a new-style submodule incompatible with older Git, which 
> may not matter all that much unless you use third-party tools 
> that come with their own version of Git embedded (which by 
> definition can become stale). 
> 
> 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? 

Excellent observation! We could do that (it's not being done in 
v3).

Currently any existing submodule gitdir names are left untouched 
and are used as-is (unencoded) after the extension is enabled.

It's been done like this for backwards compatibility, to eliminate 
any potential risk of breakage by having to move/update gitdirs, 
however maybe we've been overly cautious and we can attempt a 
"migration" once the extension is enabled, to move the submodule 
gitdirs.

> 
>> This allowed removal of the modules vs submodules directories 
>> split and simplified our logic quite a lot. Tests have been 
>> been squashed in the smaller commits as well. 
> 
> By this statement, I am guessing that the answer is yes?  That 
> would make it consistent.  The last thing we want here is the 
> code that needs to guess which ones are encoded and which ones 
> are not. 

No, not yet, though you do raise a fair point.

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.