warning: ignoring broken ref refs/remotes/origin/HEAD

Question

Since a few days ago, every time I press tab key to complete branch names in bash I see the message:

warning: ignoring broken ref refs/remotes/origin/HEAD warning: ignoring broken ref refs/remotes/origin/HEAD

For example, this is what I see when I have a branch called feature/foo and I press tab:

git checkout f

$ git checkout fwarning: ignoring broken ref refs/remotes/origin/HEAD
warning: ignoring broken ref refs/remotes/origin/HEAD
eature/

These could help https://stackoverflow.com/questions/34990734/how-to-fix-warning-ignoring-ref-with-broken-name-in-git (or) https://stackoverflow.com/questions/28894135/removing-broken-names-in-git-dropbox-conflicted-copy — Inian, Aug 22 '17 at 08:10
Do you have a branch called "origin/HEAD"?, try `git fetch` and then `git branch -r`. It maybe that you need to do some clean up. If this is the cases I can post up some clean-up functions... (like `git fetch -p` which removes local refs that have been removed on the remote). — code_fodder, Aug 22 '17 at 09:01

score 239 · Accepted Answer · answered Aug 24 '17 at 17:05

239

I encountered this recently when someone on my team deleted our old development branch from the remote. I ran this command to check the status of HEAD:

$ git symbolic-ref refs/remotes/origin/HEAD
refs/remotes/origin/old_dev

This command output the name of the old development branch, which no longer exists.

I fixed the warnings using this:

$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/new_dev

(Where "new_dev" is a branch name. Replace it with the name of the branch you want HEAD to point to.)

answered Aug 24 '17 at 17:05

kdechant

2,571
1
12
5

3

Thanks! I had the same issue when I deleted the `master` branch in my repo. – Apoorv Khatreja Jun 29 '20 at 18:08
10

I think a lot of people are going to find this around now with the trend to switch from master to main. Thanks! – Mike Jarvis Mar 10 '21 at 16:38

score 148 · Answer 2 · answered Mar 29 '18 at 16:28

148

This is a simpler solution than symbolic-ref.

Since you may have excluded the branch that origin/HEAD was initially pointed to.

1. List your remote branches with:

git branch -r

2. If it doesn't show in the results:

origin/HEAD -> origin/(something)

3. Just point it again with:

git remote set-head origin master

where "master" is the name of your primary (head) branch.

Running git branch -r again now shows origin/HEAD -> origin/(something) and the warning goes away.

answered Mar 29 '18 at 16:28

Paulo Coghi

13,724
14
68
90

14

This answer was the easiest for me to understand and digest and worked a charm. Thanks. – Lokua Mar 06 '19 at 20:45
1

Is there a rule (of thumb) regarding what `HEAD` should point to? Put another way, when would `HEAD` not point to `master`? – tim.rohrer May 06 '19 at 14:32
@tim.rohrer, the rule of thumb is to choose your most important branch to be `HEAD`. The branch that you, your team and collaborators must see first when cloning and, *most probably*, the branch from where new production releases comes from. – Paulo Coghi May 06 '19 at 16:31
Mmmm, okay. Seems the most important branch for developers would be `develop` but the production releases likely come from `master`. I can do more research, but not sure I see why we have `HEAD`. – tim.rohrer May 06 '19 at 18:40
1

When you clone a repository, your new clone will be pointing to HEAD – Paulo Coghi May 06 '19 at 20:25
And, if your developers publish on `master` the validated code created on `develop`, and releases are made from `master`, then `master` is your most important branch, and it's interesting that `HEAD` points to it. – Paulo Coghi May 06 '19 at 20:30
There are many use cases. In open source softwares that maintain more than one version (i.e. 1.0.x, 1.5.x, 2.0.x), it's common to see each important version as a separated branch, where improvements, corrections and additions can be made to a specific version, without compromising the other ones. In this case, `HEAD` normally points to the branch that represents the production branch of the most recent version. – Paulo Coghi May 06 '19 at 20:34

Simon Borsky · Answer 3 · 2021-02-21T10:13:28.407

21

Just run the command -

#replace the <branch name> with your main branch - master, main, etc.    
git remote set-head origin <branch name>

Enjoy!

edited Feb 21 '21 at 10:13

answered Sep 03 '19 at 11:24

Simon Borsky

4,979
2
22
20

4

Remember, your HEAD might not be called `master`. You must use whatever your most important branch is. e.g. `master`, `main`, `rc` whatever branch you expect a developer to be on. – Matt Jun 12 '20 at 20:55

score 8 · Answer 4 · answered May 23 '22 at 12:16

8

My solution was to delete the folder/file:

./.git/refs/remotes/origin/{branch_name}

Afterwards I was finally able to make a git fetch again.

answered May 23 '22 at 12:16

chrisaramar

271
4
10

Is not a git solution but is a little nice hack. Thank you for sharing. – sensorario May 24 '22 at 14:21
Easiest way to fix it. Thanks! – Berci Oct 27 '22 at 14:19

山茶树和葡萄树 · Answer 5 · 2021-02-18T14:23:57.897

Some problems arise after the local master renames main:

git fetch: "fatal: couldn't find remote ref refs/heads/master";
git branch -u origin/main main: "error: the requested upstream branch 'origin/main' does not exist";
git remote set-head origin main: "error: Not a valid ref: refs/remotes/origin/main";
git push -u origin main: "error: failed to push some refs to 'github.com:/.git'";
git symbolic-ref HEAD refs/heads/main or git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main or git update-ref refs/heads/main main,
- and then git branch -r: "warning: ignoring broken ref refs/remotes/origin/HEAD";

The solution to this problem:

git remote -v, copy git repository url
git remote rm origin, remove remote
git remote add origin <REPOSITORY_URL>, reset remote url
git fetch origin
git branch -u origin/main main, reset branch upstream

If just rename: `git branch -m master main` → `git fetch origin` → `git branch -u origin/main main` — 山茶树和葡萄树, Feb 18 '21 at 14:25

score 3 · Answer 6 · answered Jul 12 '22 at 20:38

3

To fix this error, remove the following file YOURPROJECT/.git/refs/remotes/origin/master, and then run git fetch to download it again. It will solve your problem.

answered Jul 12 '22 at 20:38

Yazdan Ilyas

374
4
8

The question is old. I already have a solution but thank you for your time! – sensorario Jul 14 '22 at 08:01
One should not delete files in `.git` manually, as this will often have unintended consequences. Rather, find (and learn) the proper `git` command with the intended effect. – Lutz Prechelt Aug 30 '22 at 11:34

score 2 · Answer 7 · answered May 31 '20 at 08:16

2

In my case the problem was the file .git\refs\remotes\origin\master that got corrupted, maybe since my computer was involuntary disconnected from power a few days ago.

I solved it by replacing the file content with the correct reference, a 40 char hex number that can be found in the file .git\FETCH_HEAD.

answered May 31 '20 at 08:16

cubitico

21
4

I had to do something similar as what you proposed but with destination the file .git/refs/stash that was empty – NGI Jan 03 '22 at 16:14

score 1 · Answer 8 · answered Aug 22 '17 at 11:30

1

Looks like the default branch of your remote origin doesn't exists anymore.
Fix the default branch of the remote:

GitHub: https://github.com/USER_OR_ORG/REPOSITORY/settings/branches -> "Default branch"
Bitbucket Cloud: https://bitbucket.org/USER_OR_ORG/REPOSITORY/admin -> " Main branch"
Bitbucket Server: http://git.sid.distribution.edf.fr/projects/PROJECT/repos/REPOSITORY/settings -> "Default branch"

answered Aug 22 '17 at 11:30

zigarn

10,892
2
31
45

1

I don't think this works. Changing the main or default branch is what you need to do if you want to delete that remote branch in the first place, but changing this doesn't fix the broken ref. – alondono Jul 31 '18 at 04:28

score 0 · Answer 9 · answered Sep 16 '21 at 05:32

Like already answered - The warning indicates that the remote branch no longer exists, e.g. when the remote branch is merged+deleted into another branch.

In my case I had to delete my local branch, because it was not longer needed and fixing the broken ref was not possible. Therefore, git branch -d feature/.. did the job.

warning: ignoring broken ref refs/remotes/origin/HEAD

9 Answers9