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