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

[Patrick Steinhardt <ps@pks.im>]

On Thu, Jul 03, 2025 at 09:51:12PM -0700, Junio C Hamano wrote:
> Per Cederqvist <ceder@lysator.liu.se> writes:
> 
> > 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.

We cannot just blanket-disallow this now, true. But shouldn't Git be
able to detect this conflict, similar to how a user cannot have both
refs/heads/branch and refs/heads/branch/nested?

Patrick