google/zoekt

gitindex.CloneRepo results in error with git v2.21.0

ezkl opened this issue · 3 comments

ezkl commented

Setting remote.origin.fetch to +refs/heads/*:refs/heads/* during the clone in gitindex.CloneRepo() results in an error with git v2.21.0 (released recently.)

The most straightforward way I was able to reproduce was to install both versions of git (v2.21.0 and v2.20.1) and git clone directly:

#!/usr/bin/env bash

set -x

git2.21 clone --bare --progress \
  --config "remote.origin.fetch=+refs/heads/*:refs/heads/*" \
  https://github.com/google/zoekt.git \
  /tmp/zoekt-git2.21.git

echo "status: $?"

git2.20 clone --bare --progress \
  --config "remote.origin.fetch=+refs/heads/*:refs/heads/*" \
  https://github.com/google/zoekt.git \
  /tmp/zoekt-git2.20.git

echo "status: $?"
+ git2.21 clone --bare --progress --config 'remote.origin.fetch=+refs/heads/*:refs/heads/*' https://github.com/google/zoekt.git /tmp/zoekt-git2.21.git
Cloning into bare repository '/tmp/zoekt-git2.21.git'...
remote: Enumerating objects: 155, done.
remote: Counting objects: 100% (155/155), done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 3498 (delta 78), reused 117 (delta 75), pack-reused 3343
Receiving objects: 100% (3498/3498), 1014.99 KiB | 6.26 MiB/s, done.
Resolving deltas: 100% (2293/2293), done.
fatal: multiple updates for ref 'refs/heads/master' not allowed
+ echo 'status: 128'
status: 128
+ git2.20 clone --bare --progress --config 'remote.origin.fetch=+refs/heads/*:refs/heads/*' https://github.com/google/zoekt.git /tmp/zoekt-git2.20.git
Cloning into bare repository '/tmp/zoekt-git2.20.git'...
remote: Enumerating objects: 155, done.
remote: Counting objects: 100% (155/155), done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 3498 (delta 78), reused 117 (delta 75), pack-reused 3343
Receiving objects: 100% (3498/3498), 1014.99 KiB | 6.15 MiB/s, done.
Resolving deltas: 100% (2293/2293), done.
+ echo 'status: 0'
status: 0

I was able to reproduce on both macOS 10.12 and Ubuntu 16.04. A superficial scan of recent changes to git makes me think that git/git@515be83 may be the change that introduced the problem, but I haven't verified.

hanwen commented

thanks for the report; I can confirm this. The commit indeed looks like a probable culprit.

  • 👍1
hanwen commented

I sent a mail to the git@ list.

  • 👍1