Re: Allowing "/" in the name of a git remote is a strange choice

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 4, 2025, 04:51 UTC
Message-ID: <xmqqikk8bltr.fsf@gitster.g>
In-Reply-To: <CAHx6-Um1dq0xJ-RkW+qXe=sEa6JGViSJxjzNw56u55DHLYoT2Q@mail.gmail.com>

Per Cederqvist <ceder@lysator.liu.se> writes:

Show 10 quoted lines

> Today I realized that git accepts "/" in a remote name.
>
> This can lead to problems. I have a repository that contains a branch
> called "master" and another called "chat/master". Just for fun, I
> added a second remote in this repository and named it
> "origin/chat".
>
> Now, does "refs/remotes/origin/chat/master" refer to the branch
> "chat/master" from "origin", or the branch "master" from
> "origin/chat"? Git seems to think it refers to both:

That would have been a fun experiment ;-)

> If it was up to me, I'd add a check to valid_remote_name() to ensure
> the name doesn't contain any "/" character.  I doubt it is used often.

If your remote-naming discipline is to always use two-levels (e.g. origin/chat, origin/chien, origin/lapin but never origin or origin/chat/blanc mixed in), then there is no confusion.

It becomes only confusing if you mix origin and origin/chat.

So it is not like we can just forbid '/' retroactively and expect no repercussions, especially given that I hear there are more than a few thousands of existing Git users in the world.