Re: Mirror repositories for submodules

From: Simon Richter <simon.richter@hogyros.de>
Date: Jun 4, 2026, 09:27 UTC
Message-ID: <fa075b7a-96f6-4fd9-ae94-30ddf323f759@hogyros.de>
In-Reply-To: <20260604061605.GA3194609@coredump.intra.peff.net>

Hi,

On 6/4/26 3:16 PM, Jeff King wrote:

> Here's a thought experiment. What if you put the UUID into a URL, like:
>    repoid://123456789.git

Yes, that's the idea, except I would want to use a relative URL, like

     ../123456789.git

This could solve the "naive cloning" problem, because it creates an expectation that the submodules can be found on the same server, or in a nearby path.

I'm aware that this is *also* bad for decentralization, because it makes it easier to use one of the big forges where the repositories for often-used submodules are are already likely to be present, but it plays into our use case, where we want to share the repositories for often-used subprojects.

> Now, all of that said, do we still need uuids at all? If the canonical
> submodule name is https://github.com/git/git.git, then anybody can just
> rewrite that locally in the same way using url.*.insteadOf config.

Yes, but we'd then need a mechanism for a server to indicate "for cloning, you should use these 'insteadOf' settings, which is a massive can of worms from a security standpoint.

I also don't think these canonical URLs can ever be stable if they refer to infrastructure that is not under the control of the maintainer -- it would tie the project identity to the hosting provider, and increase the inertia to overcome for moves (such as the current exodus from github and gitlab towards codeberg).

> Which makes me wonder if I am missing something about the original
> request that started this thread. But it sounds to me like it is just
> asking for the existing URL-rewriting feature.

The original mail has a similar problem as we do in Debian, and as my employer has: CI jobs should exclusively talk to in-house infrastructure, because continuously cloning repositories for each build is bad for the environment.

The common goal is that a naive clone should get submodules from a local server, ideally without us having to write some tool to make an initial checkout, enumerate submodules, create insteadOf settings, clone first layer of submodules, enumerate second layer, ...

    Simon