Re: [PATCH] remote: detect collisions in remote names

From: Raymond E. Pasco <ray@ameretat.dev>
Date: Jul 9, 2025, 11:56 UTC
Message-ID: <xra2vj7fcdsieg4xkvxlctcoubdwalgmhyswub6dxi2pnb34e3@iadinufm23ez>
In-Reply-To: <20250705185842.GA2496172@coredump.intra.peff.net>

On 25/07/05 02:58PM, Jeff King wrote:

Show 14 quoted lines

> When two remotes collide in the destinations of their fetch refspecs,
> the results can be confusing. For example, in this silly example:
> 
>   git config remote.one.url [...]
>   git config remote.one.fetch +refs/heads/*:refs/remotes/collide/*
>   git config remote.two.url [...]
>   git config remote.two.fetch +refs/heads/*:refs/remotes/collide/*
>   git fetch --all
> 
> we may try to write to the same ref twice (once for each remote we're
> fetching). There's also a more subtle version of this. If you have
> remotes "outer/inner" and "outer", then the ref "inner/branch" on the
> second remote will conflict with just "branch" on the former (they both
> want to write to "refs/remotes/outer/inner/branch").

I can give my thoughts from the perspective of someone with an affected workflow, if no one else is doing that.

I would expect '/' in remote names to be fairly common among people who name remotes at all (a minority compared to those who have one remote autonamed 'origin', probably); many things, from kernel.org to Github, use path-like names (often username/reponame) to name repositories, and the most relevant subset of that path is a natural thing to name a remote. But that part doesn't seem controversial, despite the initial message in this thread. So that's not a problem for me.

What this patch disallows, at least in porcelain, is something like (these names are just examples) my naming a remote for gregkh/linux.git "gregkh" and also naming a remote for gregkh/scsi.git "gregkh/scsi", because it might lead to colliding names if gregkh makes a branch named "scsi" on the former.

I've probably ever named remotes like this before, though I don't see any examples in repositories I'm actively using this week. It's plausible that other people have done this, or are doing it, though if I had ever shot myself in the foot doing so I would have stopped.

Because it does seem prone to annoying mishaps, I think a change like this is probably a good idea. It's not a confusing concept, because it's familiar from how branch names with '/' in them already work.

What would the 'git remote' porcelain do in cases where remotes like this already exist? I think, from this patch, nothing, since it's only changing add()?