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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 6, 2025, 17:06 UTC
Message-ID: <xmqqy0poot7g.fsf@gitster.g>
In-Reply-To: <20251006112518.3764240-6-adrian.ratiu@collabora.com>

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?

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?

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.

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.