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

>
> On Sun, Oct 25, 2026 at 12:42 PM Jacob Keller
> <jacob.keller@gmail.com> wrote:
> > 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.
>
> >> - 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.