Re: [PATCH v4 0/4] Encode submodule gitdir names to avoid conflicts

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Nov 17, 2025, 15:22 UTC
Message-ID: <87cy5gbs61.fsf@gentoo.mail-host-address-is-not-set>
In-Reply-To: <6m72swbxcm2gi2wtvgc4yxid3o64qbuckzzguzg3mzd6rmrvx5@i55v6c2nq5e4>

Hi Josh and thanks for testing & the feedback.

On Fri, 14 Nov 2025, Josh Steadmon <steadmon@google.com> wrote:

Show 14 quoted lines

> The switch to using an extension may complicate our migration a 
> bit.  Background for the list: Google has been using an early 
> version of this submodule encoding scheme for years. We have a 
> lot of users' repositories with this encoding scheme in place on 
> disk, but with no corresponding extensions.submoduleEncoding 
> config. 
> 
> I've done some limited testing; the good news is that it looks 
> like using this series with pre-encoded submodules still works, 
> regardless of the value of extensions.submoduleEncoding. It 
> would be nice to add some tests in V5 that we can create some 
> submodules with the extension enabled, and then disable it later 
> and still work with the encoded submodules (and then maybe 
> enable it once again).

Yes, I'd expect forward-migration (enabling the extension) to be very smooth. I will add some tests for backwards migration (disabling the extension) as well in v5.

Show 13 quoted lines

> 
> The first difficulty I see is that there's not a good way to 
> automatically migrate existing repos to the new extension; we'll 
> have to ask users to manually set configs on each of their 
> repos. While we are able to distribute default Git configs for 
> our users, `core.repositoryFormatValue` and `extensions.*` are 
> obviously special cases that can't be applied from 
> non-repo-local configs. I don't know what could be changed in 
> this series to avoid the issue, so I guess I'll instead just ask 
> the list for ideas for automating this migration. One idea is to 
> carry a tiny downstream patch to force-enable 
> `extensions.submoduleEncoding` regardless of the local config, 
> but maybe someone else has a better idea.

I propose to use a build-time configuration option to force-enable / set the config automatically for these types of situations.

This way you just add a flag to your builds and don't need to 
carry downstream patches, though it could also be solved with 
one-liner downstream patch. :)

Show 6 quoted lines

> 
> A second issue is that we'd like to be able to set 
> submoduleEncoding for new repositories, without requiring 
> passing a config on the command line. Perhaps we could add 
> another config option analogous to `init.defaultObjectFormat` 
> that we can set in our locally-distributed config.

This will also be solved by the build-time config option I proposed above.

I plan to send v5 soon and I'll include these changes, if nobody objects, along with everything else I've got ready.