From: Simon Richter <simon.richter@hogyros.de>
Date: Fri, 05 Jun 2026 12:10:52 GMT
Subject: Re: Mirror repositories for submodules
Message-ID: <01d627c2-3625-4de4-978e-6fa4f63bcaeb@hogyros.de>
In-Reply-To: <87h5nhr2zp.fsf@emailplus.org>

Hi,

On 6/5/26 2:05 PM, Benson Muite wrote:

> Simon Richter <Simon.Richter@hogyros.de> writes:

>> On the other hand, this can be used to construct a stable relative
>> submodule URL.

> For submodules, the metadata consists of the url of the repository to
> clone from.

That is precisely what precludes mirroring: if I clone and republish a 
repository, people can clone from that repository, but will still fetch 
submodules from the URLs listed in the .gitmodules file.

If that is a relative URL, then all is (mostly) well: they will also ask 
my mirror server for the submodule, and all I have to do is make it 
available.

If it is an absolute URL, then I need a side channel to communicate to 
the client "you can also get this repository from me." This could, for 
example, generate an insteadOf config, but that would be a horrible hack 
that becomes unmanageable pretty quickly (updates? security implications?)

Hence this thread: is there a way to represent submodules so that their 
identity is independent from the hosting location -- and this ties into 
the other thread from last week, giving projects a stable identity that 
follows them through clones (or, if someone is using a forge, forks).

The download location for a project is project metadata that lives 
outside the project view of time, but it is expressed as (versioned) 
data in git, in the .gitmodules file, so if hosting for a project 
changes, projects referring to them must either rewrite all of their 
history, accept that old versions will no longer be buildable because 
they contain a broken link, or expect people/CI to manually generate 
insteadOf entries.

So the problem here is that we are treating metadata as data.

    Simon