On Sun, Oct 25, 2026 at 12:42 PM Jacob Keller
[off-list ref] wrote:
On Tue, Sep 29, 2026 at 11:51 AM Stanislav Aleksandrov
[off-list ref] wrote:
quoted
- Why not url.<base>.insteadOf? It has to be set up on every clone;
.gitmodules cannot carry it.
Could .gitmodules be extended to carry this information?
Not as a rewrite rule. A rule maps one fixed prefix to another, and
.gitmodules is the same for everyone, so it can't send one person over
https and another over ssh with their own host alias. What differs per
clone is the superproject's remote URL, and that's what "../" and "^/"
resolve against.
We could add a separate "same server as the superproject" key next to
an absolute URL and then Git would ignore the host written in that
URL, but that would be really confusing.
quoted
- Compatibility: a local "^/..." path needs a "^" directory in the
superproject and protocol.file.allow=always, and "git submodule
add" refuses it.
What do you mean here by "refuses it" Is this character already
refused? I.e. "^" isn't considered a valid directory, which is why its
suitable for converting to a special meaning?
No, "^" is a valid directory name, and today "^/org/lib.git" means a
repository in a "^" directory of the superproject. By "refuses" I
meant that "git submodule add" rejects it, as it does "foo/lib.git":
fatal: repo URL: '^/org/lib.git' must be absolute or begin with ./|../
So such a URL has to be written into .gitmodules by hand or with "git
submodule set-url", and since 2.38.1 it can't be cloned without
protocol.file.allow=always. It is possible, just very unlikely.
The ultimate goal would be to allow users to specify what protocol
they want to operate on.
Relative URLs already do that: a superproject cloned over ssh gets its
"../" submodules over ssh too. The problem is that they also follow
where the superproject lives.
I guess "insteadOf" even in the .gitmodules wouldn't work because you
wouldn't want to apply that to everyone. The issue seems to be caused
because of the URLs on Gitlab changing such that relative paths don't
work anymore?
The URLs don't change. Forks are the problem. A fork lives in another
namespace, and on GitLab often at a different depth, because groups
can be nested.
Does doing something like "../../" work to allow the subproject to
find the root from a relative path? Or does the current logic not
support multiple ".."?
Multiple ".." work, but the count has to match how deep the
superproject is. Let's say the upstream is https://gitlab.com/org/super.git
and lib is https://gitlab.com/org/lib.git:
- "../lib.git" gives me/lib.git for a fork at me/super.git, which
only exists if lib was forked too.
- "../../org/lib.git" works for me/super.git, but gives
group/org/lib.git for a fork at group/team/super.git.
- "../../../org/lib.git" works for group/team/super.git, but for
me/super.git it climbs past the root and eats the host:
https://org/lib.git.
"^/org/lib.git" gives https://gitlab.com/org/lib.git for all of them,
or git@gitlab.com:org/lib.git if the superproject was cloned over ssh.
On GitHub every repository is two levels deep, so "../../org/lib.git"
works for everyone. GitLab and plain SSH servers have no fixed
depth.