Re: [PATCH v3 5/5] submodule: error out if gitdir name is too long

[Adrian Ratiu <adrian.ratiu@collabora.com>]

On Mon, 06 Oct 2025, Junio C Hamano <gitster@pobox.com> wrote:
> Adrian Ratiu <adrian.ratiu@collabora.com> writes: 
> 
>> Encoding submodule names increases their name size, so there is 
>> an increased risk to hit the max filename length in the gitdir 
>> path.  (the likelihood is still rather small, so it's an 
>> acceptable risk) 
> 
> If it is acceptable, can we ignore it? 

Yes, we can.

Peff actually asked if it's worth pursuing this path. We can 
certainly ignore and let the OS fail like it does now, without the 
compat wrapper.

The only usefulness of this commit as-is is to to print a nicer 
error msg and allow us to eventually address the patch TODO 
(sharding/trimming).

Please let me know if you wish to drop this commit in v4. I am 
perfectly fine with removing it. :)

> 
> Just stepping back a bit, how are we keeping track of the 
> mapping between submodule names vs locations in .git/modules/? 
> Don't we always go through that mapping and would a half-clever 
> code that says "heh, that is url encoded and I know how to 
> decode it" and bypass the mapping a bug?

The short answer is no. :) The slightly longer answer is:

Before v3, we used to have a clear filesystem separation:
.git/modules were unencoded
.git/submodules were encoded

After v3, when the extension is enabled, we encode all submodule 
names with one exception: if they already exist, at which point 
they are treated as unencoded.
 
> 
> If we keep track of the mapping ourselves, then the names under 
> .git/modules/ do not have to be "decodable" by themselves.  They 
> can even be sequence numbers and that would not hit any maximum 
> filename length before you fill your disk.

IIRC the consensus was to avoid keeping such a mapping due to 
complexity, risk of desynchronizing with the filesystem layout and 
so on, so simple rules like the above, or even a simple hash_name 
might be better (see below).
 
> 
> No, no I am not suggesting to use sequence numbers; something 
> remotely readable by humans is better.  But my point is that 
> just like you have to make sure that the encoded name you give 
> to a new thing does not collide with existing names (you know 
> with "ls .git/modules/" what names are taken), you can notice 
> your mkdir() would not error with name-too-long, truncate and 
> twiddle with suffix to make it unique and retry, without giving 
> a failure to the end user. 

Everything is on the table and I have no strong opinions. :)

Someone suggested we use something like .git/modules/<hash>_<name> 
when the extension is enabled, so we have a simple, unique and 
recognizable pattern.

What do you think of that?