From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Tue, 07 Oct 2025 17:41:02 GMT
Subject: Re: [PATCH v3 4/5] submodule: encode gitdir paths to avoid conflicts
Message-ID: <87347u4nkh.fsf@collabora.com>
In-Reply-To: <xmqqo6qik4r9.fsf@gitster.g>

On Tue, 07 Oct 2025, Junio C Hamano <gitster@pobox.com> wrote:
> Adrian Ratiu <adrian.ratiu@collabora.com> writes: 
> 
>> I will percent encode the upper case by modifying 
>> is_rfc3986_unreserved(). 
> 
> Again, do we really need to encode everything?  We need to only 
> when (1) there are other submodules that would collide with us 
> (e.g., by being only case-different, or by having our name plus 
> a slash as the prefix of their name, make us overlap with them) 
> or (2) our name is not filesystem friendly and needs munging.  A 
> letter being in an upper case is not a crime. 

Right, I see what you mean now.

The problem becomes how to detect (1) and (2), for example: a 
specific name is filesystem-friendly or is case-folding happening 
or not?

(ext4 for example can be mounted with casefolding on/off)

This is not a trivial problem, however I think it is solvable. We 
can write a few runtime tests to detect things like case-folding, 
to decide if encoding is required or not (better ideas welcome).

On the other hand, by always encoding everything we avoid the (1) 
(2) detection problems. :)

> 
>>>> 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. 
> 
> If we are to consistently use submodule.<name>.gitdirpath as the 
> authoritative collection of name-path mapping, then the exact 
> algorithm to derive path from name can be improved over time 
> without having to worry about an old submodule whose path was 
> computed by older iteration of the algorithm colliding with a 
> new submodule whose path is derived by the more modern 
> algorithm.  So I do not mind to make ourselves aware of the 
> possibility that we can tweak and improve.  But as I said 
> elsewhere, I do not think we need to even say what exactly 
> algorithm is used to the end-users. 

Got it. I'll do the submodule.<name>.gitdirpath centric design in 
v4 and will not mention the encoding algorithm to users.