On 25/07/05 02:58PM, Jeff King wrote: > 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()?
