From: Benson Muite <benson_muite@emailplus•org>
To: Simon Richter <Simon.Richter@hogyros•de>,
Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: Mirror repositories for submodules
Date: Fri, 05 Jun 2026 08:05:30 +0300 [thread overview]
Message-ID: <87h5nhr2zp.fsf@emailplus.org> (raw)
In-Reply-To: <d64e7f31-4e00-478c-ab31-b671242865fb@hogyros.de>
Simon Richter <Simon.Richter@hogyros•de> writes:
> 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"]
> 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
next prev parent reply other threads:[~2026-06-05 5:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 6:11 Mirror repositories for submodules Benson Muite
2026-06-04 1:09 ` Junio C Hamano
2026-06-04 5:11 ` Simon Richter
2026-06-04 6:16 ` Jeff King
2026-06-04 9:27 ` Simon Richter
2026-06-05 4:54 ` Benson Muite
2026-06-05 4:47 ` Benson Muite
2026-06-05 9:34 ` Matt Hunter
2026-06-05 5:05 ` Benson Muite [this message]
2026-06-05 4:37 ` Benson Muite
2026-06-05 4:57 ` Benson Muite
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h5nhr2zp.fsf@emailplus.org \
--to=benson_muite@emailplus$(echo .)org \
--cc=Simon.Richter@hogyros$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox