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 07:47:20 +0300 [thread overview]
Message-ID: <87pl25r3tz.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.
>
> 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.
>
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"]
next prev parent reply other threads:[~2026-06-05 4:47 UTC|newest]
Thread overview: 12+ 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 [this message]
2026-06-05 9:34 ` Matt Hunter
2026-06-05 5:05 ` Benson Muite
2026-06-05 12:10 ` Simon Richter
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=87pl25r3tz.fsf@emailplus.org \
--to=benson_muite@emailplus.org \
--cc=Simon.Richter@hogyros.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.