Re: [PATCH v4 4/4] submodule: fix case-folding gitdir filesystem colisions

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

On Mon, 10 Nov 2025, Aaron Schrab <aaron@schrab.com> wrote:
> At 19:11 +0200 10 Nov 2025, Adrian Ratiu 
> <adrian.ratiu@collabora.com> wrote: 
>>On Sat, 08 Nov 2025, Aaron Schrab <aaron@schrab.com> wrote: 
>>>What happens if `Foo` is added first and doesn't conflict with 
>>>anything,  then later a new submodule is added which would 
>>>naturally  get the name  `foo` which would conflict and doesn't 
>>>have any upper  case characters to  encode to avoid the 
>>>conflict? 
> 
>>Right now, in v4, in this case the user adding the second `foo` 
>>module  will have to manually set the submodule.foo.gitdir 
>>config to avoid the  conflict, because Foo already uses the 
>>coliding path. 
> 
> I think that description minimizes the impact. I'd think that 
> anyone  with a prior clone (on a case-folding file system) would 
> need to take  that action after pulling the change that added 
> the new submodule.

No, because the extension is disabled by default.

> 
> If action were needed only when running `git submodule add`, I 
> think  that would be fine. But requiring that action in all 
> clones seems a bit  much. Some of those clones may even be 
> managed with automation making it  even more of a problem to add 
> that new configuration. 

The extension is opt-in: by default it does nothing. :)

When the extension is enabled, all existing submodules are 
automatically added to submodule.<name>.gitdir config without user 
intervention.

Enabling the extension guarantees that config exists for all 
repositories, unless there is a conflict we cannot solve, like you 
pointed above, which is typically only for very rare corner-cases 
(that's the intention).

> 
> The action may even be required in new clones, unless the 
> submodule  setup process for new clones sorts entries so that 
> ones with capital  letters come later. Since some common 
> collation rules (thinking mainly  of the `C` locale) will put 
> capital letters first I think that's  unlikely to be the case. 

The more I think about this, the more I'm convinced the second 
option (see bleow) is the way to go, which is also more in line 
with Junio's design to try a new path when validation fails and 
repeat.

>>Maybe we could derive a new path automatically (eg foo2 or foo_, 
>>suggestions welcome) and use it if valid. This way, there is no 
>>user  intervention.   Do you have any preference? 
> 
> I certainly don't have a *strong* preference. But, I think 
> `foo2` seems  a bit clearer. Although the implied strategy there 
> for multiple  conflicting names may be too complex for a 
> situation that will likely be  exceedingly rare. 

The resolution algorithm is pretty simple:
1. Create a path candidate.
2. Validate if it works: if not, go back to step 1.

We can do this any number of times for all the edge cases we can 
detect.

If foo2 also has a conflict, we can just try something else.

If all else fails, we can even hash the submodule name ;)