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

On 2025.11.07 17:05, Adrian Ratiu wrote:

Disclaimer for the list: Google is funding Adrian's work on this series; noting this now for transparency.

Hi Adrian, sorry for missing the last couple of versions of this series.

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).

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.

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.