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
