From: Simon Richter <Simon.Richter@hogyros•de>
To: Jeff King <peff@peff•net>
Cc: Junio C Hamano <gitster@pobox•com>,
Benson Muite <benson_muite@emailplus•org>,
git@vger•kernel.org
Subject: Re: Mirror repositories for submodules
Date: Thu, 4 Jun 2026 18:27:31 +0900 [thread overview]
Message-ID: <fa075b7a-96f6-4fd9-ae94-30ddf323f759@hogyros.de> (raw)
In-Reply-To: <20260604061605.GA3194609@coredump.intra.peff.net>
Hi,
On 6/4/26 3:16 PM, Jeff King wrote:
> Here's a thought experiment. What if you put the UUID into a URL, like:
> repoid://123456789.git
Yes, that's the idea, except I would want to use a relative URL, like
../123456789.git
This could solve the "naive cloning" problem, because it creates an
expectation that the submodules can be found on the same server, or in a
nearby path.
I'm aware that this is *also* bad for decentralization, because it makes
it easier to use one of the big forges where the repositories for
often-used submodules are are already likely to be present, but it plays
into our use case, where we want to share the repositories for
often-used subprojects.
> Now, all of that said, do we still need uuids at all? If the canonical
> submodule name is https://github.com/git/git.git, then anybody can just
> rewrite that locally in the same way using url.*.insteadOf config.
Yes, but we'd then need a mechanism for a server to indicate "for
cloning, you should use these 'insteadOf' settings, which is a massive
can of worms from a security standpoint.
I also don't think these canonical URLs can ever be stable if they refer
to infrastructure that is not under the control of the maintainer -- it
would tie the project identity to the hosting provider, and increase the
inertia to overcome for moves (such as the current exodus from github
and gitlab towards codeberg).
> Which makes me wonder if I am missing something about the original
> request that started this thread. But it sounds to me like it is just
> asking for the existing URL-rewriting feature.
The original mail has a similar problem as we do in Debian, and as my
employer has: CI jobs should exclusively talk to in-house
infrastructure, because continuously cloning repositories for each build
is bad for the environment.
The common goal is that a naive clone should get submodules from a local
server, ideally without us having to write some tool to make an initial
checkout, enumerate submodules, create insteadOf settings, clone first
layer of submodules, enumerate second layer, ...
Simon
next prev parent reply other threads:[~2026-06-04 9:27 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
2026-06-04 6:16 ` Jeff King
2026-06-04 9:27 ` Simon Richter [this message]
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=fa075b7a-96f6-4fd9-ae94-30ddf323f759@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 \
--cc=peff@peff$(echo .)net \
/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