Re: [RFC PATCH] submodule: make '^/' work like '../' but with an absolute path

From: Stanislav Aleksandrov <lightofmysoul@gmail.com>
Date: Oct 25, 2026, 21:25 UTC
Message-ID: <20261025212517.479922-1-lightofmysoul@gmail.com>
In-Reply-To: <CA+P7+xoSd2rsHpw+n5vCrcqXRibG6zH+SKCsVXA0OW-VZN_+=g@mail.gmail.com>

On Sun, Oct 25, 2026 at 12:42 PM Jacob Keller <jacob.keller@gmail.com> wrote:

Show 6 quoted lines

> On Tue, Sep 29, 2026 at 11:51 AM Stanislav Aleksandrov
> <lightofmysoul@gmail.com> wrote:
>> - 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.

Show 7 quoted lines

>> - 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.