Bug when cloning a repository with a default branch called HEAD

Bug when cloning a repository with a default branch called HEAD

[Björn Kautler]

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

Re: Bug when cloning a repository with a default branch called HEAD

[Bagas Sanjaya]

Hi,

On 29/05/21 02.05, Björn Kautler wrote:
> 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:
> 

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:

> fatal: 'HEAD' is not a valid branch name.

Thus I can't reproduce this issue.

> $ 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
> 

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

-- 
An old man doll... just what I always wanted! - Clara

Re: Bug when cloning a repository with a default branch called HEAD

[asymptosis]

>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
>
> /snip
>
>The remote [1] might misconfigured default branch, so instead of 
>master/main it pointed to HEAD, and it caused the issue.

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.

Fwd: Bug when cloning a repository with a default branch called HEAD

[Björn Kautler]

---------- 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

RE: Bug when cloning a repository with a default branch called HEAD

[Randall S. Becker]

>-----Original Message-----
>From: <Bjoern@kautler.net>
On May 31, 2021 4:38 PM, Björn Kautler wrote:
>Subject: Re: Bug when cloning a repository with a default branch called HEAD
>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

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

Re: Bug when cloning a repository with a default branch called HEAD

[Björn Kautler]

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>:
>
> 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.
>
> Randall S. Becker <rsbecker@nexbridge.com> schrieb am Mo., 31. Mai 2021, 22:46:
>>
>> >-----Original Message-----
>> >From: <Bjoern@kautler.net>
>> On May 31, 2021 4:38 PM, Björn Kautler wrote:
>> >Subject: Re: Bug when cloning a repository with a default branch called HEAD
>> >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
>>
>> 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
>>