Skip to contentSkip to conversation

git fetch doesn't ignore funny refs

DISCUSSION Lorenzo Keller 2 participants 2 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

Hello,

I'm trying to maintain a mirror of a repo that is published with gerrit. The repo contains
a "funny ref" with name 'refs/tags/xyz/...' .

When I clone the repo the ref is correctly ignored:

Quoted 1 line

git clone --mirror ssh://server:29418/repo

Cloning into bare repository 'repo.git'...
error: * Ignoring funny ref 'refs/tags/xyz/...' locally
remote: Counting objects: 58263, done
remote: Finding sources: 100% (58263/58263)
remote: Total 58263 (delta 40882), reused 58131 (delta 40882) Receiving objects: 100% (58263/58263), 16.10 MiB | 163.00 KiB/s, done. Resolving deltas: 100% (40882/40882), done.
Checking connectivity... done.

When I try to update the mirror, however, the command fails:

Quoted 1 line

git remote update

Fetching origin
error: * Ignoring funny ref refs/tags/xyz/...' locally From ssh://server:29418/repo
! [new tag] xyz/... -> xyz/... (unable to update local ref)
error: Could not fetch origin

Doing a fetch also fails:

Quoted 1 line

git fetch --all

Fetching origin
error: * Ignoring funny ref 'refs/tags/xyz/...' locally From ssh://server:29418/repo
! [new tag] xyz/... -> xyz/... (unable to update local ref)
error: Could not fetch origin

If I force not to update the tags, then the command is successful:

Quoted 1 line

git fetch --all -n

Fetching origin
error: * Ignoring funny ref 'refs/tags/xyz/...' locally

I believe the problem is due to the fact that in function find_non_local_tags() in file builtins/fetch.c
the refs are directly obtained from the transport and not filtered for funny entries.

A check as this one:

if (check_refname_format(ref->name, 0))
continue;

fixes the problem for me.

I report here bug and fix in the hope it can be reviewed and integrated in future git releases.

Best regards,
Lorenzo Keller

#1 lore raw
Quoted 9 lines · Lorenzo Keller

A check as this one:

if (check_refname_format(ref->name, 0))
continue;

fixes the problem for me.

I report here bug and fix in the hope it can be reviewed and integrated in future git releases.

Since it seems you already have a fix: How about sending a proper patch (possibly you want to extend this with a warning message) so people can discuss and integrate your fix here? See Documentation/SubmittingPatches for further information.

Cheers Heiko