On Tue, 09 Sep 2025, Patrick Steinhardt <ps@xxxxxx> 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!
