Bug when cloning a repository with a default branch called HEAD

Hi,

I'm not right now sure why this repo is in this state or how it got there, but that doesn't matter. But if you clone it, everything is fine. And if you then try to fetch it, Git goes havoc:

$ git clone https://gitlab.com/Vampire/whelk.git/ && cd whelk &&
GIT_TRACE=1 git fetch; echo $?
Cloning into 'whelk'...
remote: Enumerating objects: 525, done.
remote: Counting objects: 100% (525/525), done.
remote: Compressing objects: 100% (227/227), done.
remote: Total 525 (delta 280), reused 525 (delta 280), pack-reused 0
Receiving objects: 100% (525/525), 165.63 KiB | 3.52 MiB/s, done.
Resolving deltas: 100% (280/280), done.
21:04:15.761530 exec-cmd.c:237          trace: resolved executable
dir: C:/Program Files/Git/mingw64/bin
21:04:15.765532 git.c:447               trace: built-in: git fetch
warning: refname 'HEAD' is ambiguous.
21:04:15.769530 run-command.c:667       trace: run_command:
GIT_DIR=.git git remote-https origin
https://gitlab.com/Vampire/whelk.git/
21:04:15.795532 exec-cmd.c:237          trace: resolved executable
dir: C:/Program Files/Git/mingw64/libexec/git-core
21:04:15.799535 git.c:734               trace: exec: git-remote-https
origin https://gitlab.com/Vampire/whelk.git/
21:04:15.799535 run-command.c:667       trace: run_command:
git-remote-https origin https://gitlab.com/Vampire/whelk.git/
21:04:15.832533 exec-cmd.c:237          trace: resolved executable
dir: C:/Program Files/Git/mingw64/libexec/git-core
21:04:16.438060 run-command.c:667       trace: run_command: git
rev-list --objects --stdin --not --all --quiet --alternate-refs
21:04:16.461060 run-command.c:667       trace: run_command: git
rev-list --objects --stdin --not --all --quiet --alternate-refs
21:04:16.475738 exec-cmd.c:237          trace: resolved executable
dir: C:/Program Files/Git/mingw64/libexec/git-core
21:04:16.478705 git.c:447               trace: built-in: git rev-list
--objects --stdin --not --all --quiet --alternate-refs
error: multiple updates for 'refs/remotes/origin/HEAD' (including one
via symref 'refs/remotes/origin/HEAD') are not allowed
From https://gitlab.com/Vampire/whelk
 ! [new branch]      HEAD       -> origin/HEAD  (unable to update local ref)
error: some local refs could not be updated; try running
 'git remote prune origin' to remove any old, conflicting branches
21:04:16.496254 run-command.c:667       trace: run_command: git
maintenance run --auto --no-quiet
21:04:16.510254 exec-cmd.c:237          trace: resolved executable
dir: C:/Program Files/Git/mingw64/libexec/git-core
21:04:16.512256 git.c:447               trace: built-in: git
maintenance run --auto --no-quiet
1

Cheers Björn

Hi,

On 29/05/21 02.05, Björn Kautler wrote:

I'm trying to create minimal reproducible test repo by switching initial branch to HEAD:

$ mkdir shark && cd shark $ git init $ git checkout -b HEAD

But when I checkout, it returned error as expected:

Thus I can't reproduce this issue.

The remote [1] might misconfigured default branch, so instead of master/main it pointed to HEAD, and it caused the issue.

Thanks.

[1]: https://gitlab.com/Vampire/whelk

Hi Bagas,

I think he meant the remote had its default branch set to HEAD before he tried cloning. I.e. reproducing the error would look something more like this:

#! /bin/bash remote_repo=/tmp/remote local_repo=/tmp/local mkdir $remote_repo cd $remote_repo git init -b HEAD touch README git add -A && git commit -m "Initial commit" cd .. git clone $remote_repo $local_repo

For me, the generated /tmp/local repo does issue warnings about ambiguous HEAD ref. However, it still works, and I don't get the wild errors like reported by Björn.

I suspect it's something to do with the implementation on the local OS. I'm on Linux and it seems like Björn is using Windows.

---------- Forwarded message ---------
Von: Björn Kautler <Bjoern@kautler.net>
Date: Mo., 31. Mai 2021 um 22:24 Uhr
Subject: Re: Bug when cloning a repository with a default branch called HEAD
To: asymptosis <asymptosis@posteo.net>

It happens the same no matter whether on Windows or Linux.
I now also have a reproduction recipe on how to get into that state.
- Create the `whelk` repository with standard settings, nothing for
default branch or anything is necessary
- Execute this: git clone https://github.com/seveas/whelk.git
whelk-src && git -C whelk-src remote add gitlab git@gitlab.com:<your
namespace>/whelk.git && git -C whelk-src push gitlab
refs/remotes/origin/*:refs/heads/* && git clone
git@gitlab.com:git-spindle-test-vampire-1/whelk.git && git -C whelk
fetch

Cheers Björn

On May 31, 2021 4:38 PM, Björn Kautler wrote:

According to GitHub, the default branch for this repo is "main" not "HEAD". AFAIK, HEAD is a reserved ref in git and I don't think this would or should work.

Just saying. Randall

Don't get me wrong, I neither want that nor intended this result. This happened in the test suite of git-spindle which does commands similar to what I showed as reproducer now and I just wondered what is happening.

Imho a simple push should not be able to produce an unusable state and I think this was not the case in the past as the tests used to work. But this could also be caused by changes in the used fixture repo.

Am Mo., 31. Mai 2021 um 22:52 Uhr schrieb Björn Kautler <Bjoern@kautler.net>: