Re: [PATCH v3 0/5] Encode submodule gitdir names to avoid conflicts

[Junio C Hamano <gitster@pobox.com>]

Adrian Ratiu <adrian.ratiu@collabora.com> 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.<name>.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.<name>.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.<name>.gitdirpath is the only and
     authoritative place to learn how <name> 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?