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

[Jeff King <peff@peff.net>]

On Thu, Jul 03, 2025 at 09:33:20PM +0200, Per Cederqvist wrote:

> > $ git fetch --all
> > Fetching origin
> > From $PRIVATE_URL
> >  + 4e31956300f...30e26ebbb19 chat/master -> origin/chat/master  (forced update)
> > Fetching origin/chat
> > From  $PRIVATE_URL
> >  + 30e26ebbb19...4e31956300f master     -> origin/chat/master  (forced update)
> 
> Every time I run "git fetch --all" git updates the origin/chat/master ref twice.
> 
> 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.

I think the "/" here is really just a special case of a more general
problem: overlapping fetch refspec destinations.

For example, try this:

  git init repo
  cd repo

  git init one
  git -C one commit --allow-empty -m foo

  git init two
  git -C two commit --allow-empty -m bar

  git config remote.one.url one
  git config remote.one.fetch +refs/heads/*:refs/remotes/collide/*
  git config remote.two.url two
  git config remote.two.fetch +refs/heads/*:refs/remotes/collide/*

  git fetch --all

which gives similar output to what you showed above. Of course it's
easier to see here when the names are identical rather than one being a
prefix of the other. But it's fundamentally the same issue, and
forbidding "/" would not fix it.

We could perhaps detect these kinds of overlap, but I wonder:

  1. How expensive is it to do so, and when should we do it? Obviously
     for a handful of refs a quadratic approach is OK. But what if you
     had 10,000 remotes (this is not purely hypothetical; GitHub used to
     manage object migration in its fork networks with configured
     remotes, but hit enough performance issues to switch away from
     that). So I'd be hesitant to check this on every "git fetch".

  2. Is it something people actually want to do? It's certainly a
     _weird_ configuration, but I could imagine there being useful
     corner cases (e.g., one URL is an infrequently backup of the other,
     so you don't usually do "--all", or you set skipDefaultUpdate for
     one of them.

So I dunno. It feels like a configuration error in most cases, but not
all. I'd probably say that people touching the config manually should be
allowed to do what they want, but maybe "git remote" should be a bit
more careful about names being proper subsets of existing remotes (it
should already prevent the exact-match above, I'd think, because the ref
namespace it uses will always match the configuration name).

-Peff