From: Adrian Ratiu Date: Tue, 07 Oct 2025 16:58:05 GMT Subject: Re: [PATCH v3 0/5] Encode submodule gitdir names to avoid conflicts Message-ID: <878qhm4pk2.fsf@collabora.com> In-Reply-To: On Tue, 07 Oct 2025, Junio C Hamano wrote: > Adrian Ratiu writes: > >> Currently any existing submodule gitdir names are left >> untouched and are used as-is (unencoded) after the extension >> is enabled. > > And in order to make sure that a funny names and paths in > existing submodules that can be misinterpreted as encoded would > be registered with the new submodule..gitdirpath variable? > > That would be a robust way to transition. It also means that > you have a mapping from submodule name to path, and you will > have to make an effort to maintain that mapping and the reality > on the filesystem in sync. > > So why not take advantage of the fact that you are making that > effort anyway? It can simplify things quite a bit. Imagine > what would happen if we did this: > > - You officially declare that submodule..gitdirpath is > _the_ > mapping mechanism, not a mere "override". > > - When enabling the extension, you register all submodules that > already has their gitdirs on the filesystem to the mapping > mechanism under their "historical and natural" names. > > - When you add a new submodule, you "munge" its name to be used > as > a subdirectory name under .git/modules/. You only specify > for the end users the purpose and nature of this munging, > perhaps like > > - (purpose) We give each submodule a place in .git/modules > directory of the superproject to store its repository data, > but the names of submodules we find in .gitmodules may not > necessarily be friendly to the filesystem (e.g., "CON:", or > longer than the filesystem allows for a single path > component), or may introduce a subdirectory (e.g., slashes > and backslashes), or two directories whose names only > differ in case may not coexist on your filesystem. That is > why we do not use the name found in .gitmodules as-is. > > - (nature) This "munging" would remove problematic bytes or > replace them with safe ones in the name, or truncate overly > long string, or insert sequence numbers to make the result > unique and representable on the filesystem. Hopefully the > result of the munging may still be recognisable as derived > from the original name, but it is *not* designed to be > reversible by itself. The submodule..gitdirpath is > the only and authoritative place to learn how got > munged to produce a path. > > without having to go into the details to avoid tempting users > to write scripts that guess and decode bypassing the mapping. > > Hmm? Yes, I think that can work. Will do in v4. Thanks!