Re: Mirror repositories for submodules

From: Benson Muite <benson_muite@emailplus.org>
Date: Jun 5, 2026, 05:05 UTC
Message-ID: <87h5nhr2zp.fsf@emailplus.org>
In-Reply-To: <d64e7f31-4e00-478c-ab31-b671242865fb@hogyros.de>

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

Show 44 quoted lines

> Hi,
>
> On 6/4/26 10:09 AM, Junio C Hamano wrote:
>
>> So, no, I do not think a contribution to add mirror repositories as
>> alternate submodule sources should be considered for inclusion, as
>> it artificially limits usefulness of the feature.  A feature to add
>> mirror repositories as alternate sources might be worth considering,
>> though.
>
> This is relevant to the Debian use case: we run a git server that 
> archives git trees for Debian packages, and ideally the objects on this 
> server should be identical to what you get from upstream projects.
>
> This is a big problem for archiving projects that use submodules, 
> because we cannot alter the reference URLs.
>
> Cloning from our server will, depending on what upstream uses, either a 
> relative URL (which will go to our server, but we have little control 
> over what the name part of the repository base URL is going to be), or 
> an absolute URL that instructs clients to pull from another place, which 
> conflicts with our goal to have a self-contained archive.
>
> The idea posited earlier, to have a "repository identity" that remains 
> the same across forks and clones, is somewhat appealing, but the best 
> idea I can come up with is generating some kind of repository UUID, and 
> adding a symlink -- not a great design because it pollutes outside the repo:
>
>      $ mkdir myproject
>      $ cd myproject
>      $ git init
>      $ ls -l ..
>      lrwxrwxrwx 1 simon simon   9 Jun  4 14:05 
> 12345678-9abc-def0-1234-56789abcdef0.git -> myproject
>      drwxrwxr-x 2 simon simon  40 Jun  4 14:04 myproject
>
> On the other hand, this can be used to construct a stable relative 
> submodule URL.
>
> Making the symlinks optional would require keeping a list of local 
> clones and their UUIDs, and resolving them.
>
> I don't like that design, but as I said it's the best idea I have for now.
>

For submodules, the metadata consists of the url of the repository to clone from. One could have a list of absolute URLs. The default would be to assume that the URLs are tried in order, and if a URL times out, the next one would be tried. One may want to change the default ordering as a user setting, or do a ping test to get obtain content from the closest repository.

As an example, for linphone-desktop, the first part of the .gitmodules file contains:

[submodule "linphone-sdk"]
path = external/linphone-sdk
         url = https://gitlab.linphone.org/BC/public/linphone-sdk.git
[submodule "external/google/gn"]

This could be updated to

[submodule "linphone-sdk"]
path = external/linphone-sdk
         url = https://gitlab.linphone.org/BC/public/linphone-sdk.git
         url = https://github.com/BelledonneCommunications/linphone-sdk.git
[submodule "external/google/gn"]

Show 7 quoted lines

> I also fully expect that Debian's servers will be used by a lot of 
> people outside the project as soon as it becomes a convenient fallback, 
> in the same way people are pulling .orig.tar.gz archives from Debian 
> mirrors, so we need to make it easy to set up a mirror, to allow this to 
> scale.
>
>     Simon