Subject: Re: [PATCH v3 4/5] submodule: encode gitdir paths to avoid conflicts

From: Adrian Ratiu <[email-masked]>
Date: Tue, 07 Oct 2025 17:10:39 +0300

On Mon, 06 Oct 2025, Junio C Hamano <[email-masked]> wrote:
> Adrian Ratiu <[email-masked]> writes: 
> 
>> A custom encoding can become unnecessarily complex, while 
>> url-encoding is relatively well-known, however it needs some 
>> extending to support case insensitive filesystems, hence why A 
>> is encoded as _a, B as _b and so on. 
> 
> Why 'A' cannot be encoded as %41 while encodign 'a' as %61?  Are 
> there case insensitive filesystems that cannot see the 
> difference between %41 and %61?  And they would not collide with 
> COM: and other anomalies, would they? 

That is correct.

The only reason I chose A -> _a and so on is because it was 
suggested in the initial thread from 8+ years ago when people 
discussed creating a custom encoding, but we can use anything 
else.

I will percent encode the upper case by modifying 
is_rfc3986_unreserved().
 
>> For now url-encoding is the only option, however in the future 
>> we may add alternatives (other encodings, hashes or even 
>> hash_name). 
> 
> Let's not say "For now". 
> 
> Choose a single encoding that we can use forever so that we do 
> not have to upgrade extensions.encodeSubmoduleName with suffixes 
> like extensions.encodeSubmoduleNamev2, 
> extensions.encodeSubmoduleNamev3, etc. to cover our earlier 
> mistakes and force renaming on users. 

Understood. Will drop that idea.