From: Adrian Ratiu Date: Mon, 10 Nov 2025 18:27:45 GMT Subject: Re: [PATCH v4 4/4] submodule: fix case-folding gitdir filesystem colisions Message-ID: <87bjl9kaji.fsf@collabora.com> In-Reply-To: <20251110T173154Z.Hhi6cUjqDOat@fnord.qqx.org> On Mon, 10 Nov 2025, Aaron Schrab wrote: > At 19:11 +0200 10 Nov 2025, Adrian Ratiu > wrote: >>On Sat, 08 Nov 2025, Aaron Schrab 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..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 ;)