From: Adrian Ratiu Date: Tue, 09 Sep 2025 17:46:25 GMT Subject: Re: [PATCH v2 03/10] submodule: add gitdir path config override Message-ID: <87bjnj7c3y.fsf@collabora.com> In-Reply-To: On Tue, 09 Sep 2025, Patrick Steinhardt wrote: > On Mon, Sep 08, 2025 at 05:01:10PM +0300, Adrian Ratiu wrote: >> This adds an ability to override gitdir paths via config files >> (not .gitmodules), such that any encoding scheme can be changed >> and JGit & co don't need to exactly match the default encoding. >> A new test and a helper are added. The helper will be used by >> further tests exercising gitdir paths & encodings. > > Aha, so you already do what I'm lamenting about in the preceding > commit. Not quite. I tried to explain in my previous reply that this only looks similar and perhaps I should have worded the commit message differently (I promised Phillip I'll reword it), however it's intended just to allow simple overrides, without being a unified way for all implementations to work with gitdirs. :) > It still raises the question around how to handle this whole > migration now, as alternative implementations don't yet know > about this specific config key. Doing all of this in a single > patch series will most likely result in breakage. > > In theory, we should probably first introduce the configuration, > then wait a couple releases for alternative implementations to > catch up, and then switch over. But we still cannot be sure that > implementations know to handle this key alright. Exactly, they won't. :) > > A heavy-handed solution to this would be to introduce a > repository extension. This would ensure that any well-behaved > Git client will refuse to open the repository if it doesn't know > about that specific extension. With the remaining ones we can be > sure that they know to handle the "submodule.*.gitdir" > configuration. > > As mentioned, extensions are rather heavy-handed. Furthermore, > this whole infra is only really needed under very specific > circumstances. So maybe it could be a viable approach to make > this extension opt-in: > > - We provide a new configuration > "init.useSubmoduleGitdirExtension" > that tells git-init(1) and git-clone(1) to use the new > extension for newly initialized repositories. > > - We detect the situation where a submodule cannot be cloned > due to a > path conflict. If detected, we print a user-facing hint that > tells them to enable the extension. This is actually a very good idea, to detect path conflicts and print a nice message to instruct the user to enable the extension, instead of the default "error: git dir is inside git dir" or somesuch confusing msg. I'll work on it for patch v3 and add some tests. > > Once the user enabled the extension we'll know to use new, > encoded submodule paths from thereon and thus re-initializing > the conflicting submodule should work now. > > With all of this I wonder whether we even need a new > ".git/submodules" directory. Couldn't we just continue to create > submodules in the old path and for example create a random > suffix as required? Now that we decided to put this logic behind an extension, we might get away with having a unified directory, yes. It's something I'll explore for v3. I would really like to avoid having both "modules" and "submodules" alongside eachother. > > In any case, please stop me if I'm going overboard with my > backwards compatibility concerns :) You have good ideas and your feedback is much appreciated. Kudos and thanks!