From: Simon Richter <Simon.Richter@hogyros•de>
To: Junio C Hamano <gitster@pobox•com>,
Benson Muite <benson_muite@emailplus•org>
Cc: git@vger•kernel.org
Subject: Re: Mirror repositories for submodules
Date: Thu, 4 Jun 2026 14:11:38 +0900 [thread overview]
Message-ID: <d64e7f31-4e00-478c-ab31-b671242865fb@hogyros.de> (raw)
In-Reply-To: <xmqqcxy7qfgk.fsf@gitster.g>
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.
Simon
next prev parent reply other threads:[~2026-06-04 5:11 UTC|newest]
Thread overview: 10+ 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 [this message]
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 5:05 ` Benson Muite
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=d64e7f31-4e00-478c-ab31-b671242865fb@hogyros.de \
--to=simon.richter@hogyros$(echo .)de \
--cc=benson_muite@emailplus$(echo .)org \
--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