Re: [PATCH 2/2] submodule: munge paths to submodule git directories

From: Jeff King <peff@peff.net>
Date: Aug 29, 2018, 21:03 UTC
Message-ID: <20180829210348.GA29880@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kZv4BjRq=kq_1UeT2Kn38OZwYFgnMsTe6X_WP41=hBtSQ@mail.gmail.com>

On Wed, Aug 29, 2018 at 11:10:51AM -0700, Stefan Beller wrote:

Show 16 quoted lines

> > Do you care about case-folding issues (e.g., submodules "FOO" and "foo"
> > colliding)?
> 
> I do. :(
> 
> 2d84f13dcb6 (config: fix case sensitive subsection names on writing, 2018-08-08)
> explains the latest episode of case folding with submodules involved.
> 
> > I'm OK if the answer is "no", but if you do want to deal with it, the
> > time is probably now.
> 
> Good point. But as soon as we start discussing case sensitivity, we
> are drawn down the rabbit hole of funny file names. (Try naming
> a submodule "CON1" and obtain it on Windows for example)
> So we would need to have a file system specific encoding function for
> submodule names, which sounds like a maintenance night mare.

Hmph. I'd hoped that simply escaping metacharacters and doing some obvious case-folding would be enough. And I think that would cover most accidental cases. But yeah, Windows reserved names are basically indistinguishable from reasonable names. They'd probably need special-cased.

OTOH, I'm not sure how we handle those for entries in the actual tree. Poking around git-for-windows/git, I think it uses the magic "\\?" marker to tell the OS to interpret the name literally.

So I wonder if it might be sufficient to just deal with the more obvious folding issues. Or as you noted, if we just choose lowercase names as the normalized form, that might also be enough. :)

Show 6 quoted lines

> So if I was thinking in the scheme presented above, we could just
> have another rule that is
> 
>   [A-Z]  -> _[a-z]
> 
> (lowercase capital letters and escape them with an underscore)

Yes, that makes even the capitalized "CON" issues go away. It's not a one-to-one mapping, though ("foo-" and "foo_" map to the same entity).

If we want that, too, I think something like url-encoding is fine, with the caveat that we simply urlencode _more_ things (i.e., anything not in [a-z_]).

-Peff