[ACCEPTED]-Git unable to resolve references when pushing-github
(a worthwhile tl;dr from @NeTeInStEiN:
The 25 nuclear option is
rm -rf .git/refs/remotes/origin, and that's what it took 24 here)
edit: I've run across part of this behavior 23 in one of my own repos, I can get git to 22 reproduce the f-e-r failure without the 21
rm .git/refs/remotes/origin/master hack:
- clone a repo
- delete the origin's primary branch (the one its
HEAD's attached to)
git fetch --prunein the clone
The fetch will produce a dangling-ref 20 warning, and
git for-each-ref will fail with a familiar 19 message:
~/sandbox/20/buddy$ git fetch --prune From /home/jthill/sandbox/20/source/. x [deleted] (none) -> origin/master (refs/remotes/origin/HEAD has become dangling) ~/sandbox/20/buddy$ git f-e-r fatal: missing object 0000000000000000000000000000000000000000 for refs/remotes/origin/HEAD
but that doesn't break the push, I've 18 tried with every setting of
push.default, nor does it 17 break
git update-ref -d.
However, googling the push message 16 did get me this:
I had just rebooted from a BSOD the other day [...] then git push. And that’s when I got a complaint about “Unable to resolve reference refs/remotes/origin/master…”. [...] So, I opened up the master file and it was full of spaces! Well, that’s no good. In order to fix it, I did this: [your
rm, and then
See comments above for the 15 blow-by-blow, tl;dr is, because these were 14 remote refs, which
git fetch completely refreshes, and 13 because the damage was such that
git update-ref failed 12 to work at all, the nuclear option
rm -rf refs/remotes/origin; git fetch was 11 guaranteed to restore the remote properly.
In 10 other circumstances, if there'd been no 9 easy way to restore the damaged refs or 8 for curiosity,
find .git/refs/remotes/origin -type f to check for locks or using 7 reflogs (those files are in
.git/logs) to recover 6 content would have helped but it wasn't 5 necessary here. I think I missed a bet 4 by not doing the
*.lock files from a
kill -9ed 3 earlier command look likely here, but I 2 suspected an ambiguous ref and f-e-r is 1 my first step for those.
Remove the following directory from .git 4 folder -> .git/refs/remotes/origin
This will 3 remove all the remote branches and you need 2 to fetch them again using -> git fetch. This 1 should fix the issue.
- just go to this dir. in your project and delete the origin folder from your project:
- now just run this commannd:
git fetch --prune
or you may fetch all your branches by using 2 this
git fetch --all.
pull your code with,
this works 1 for me,
Note: with Git 2.5 (July 2015),
git for-each-ref will be 14 a bit more precise when it fails on a "missing 13 object".
See commit 501cf47, commit f551707 (03 Jun 2015), and commit 8afc493, commit c3e23dc (02 12 Jun 2015) by Michael Haggerty (
(Merged by Junio C Hamano --
gitster -- in commit 9d71c5f, 24 Jun 2015)
for-each-ref: report broken references correctly
If there is a loose reference 11 file with invalid contents, "
git for-each-ref" incorrectly 10 reports the problem as being a missing object 9 with name NULL_SHA1:
$ echo '12345678' >.git/refs/heads/nonsense $ git for-each-ref fatal: missing object 0000000000000000000000000000000000000000 for refs/heads/nonsense
With an explicit "
--format" string, it 8 can even report that the reference validly 7 points at NULL_SHA1:
$ git for-each-ref --format='%(objectname) %(refname)' 0000000000000000000000000000000000000000 refs/heads/nonsense $ echo $? 0
NULL_SHA1is used to indicate 6 an "
invalid object name" throughout our code (and 5 the code of other git implementations), so 4 it is vastly more likely that an on-disk 3 reference was set to this value due to a software 2 bug than that
NULL_SHA1is the legitimate SHA-1 of 1 an actual object.
Therefore, if a loose reference has the value
NULL_SHA1, consider it to be broken.
run git 1 fetch --prune
I am probably a day late and a dollar short, but 6 I recently experienced the same error message 5 while setting up my first repository for 4 school. I have looked at the answers above 3 and none of them solved my problem. What 2 did solve my problem was :
sudo git push and entered 1 admin password...
The easy way to solve this is to first check 6 if the git repository you are pushing your 5 commits is getting updated with your commits 4 or not. If yes then you can delete the cloned 3 repository on your local machine and then 2 again clone it. This way the error will 1 go away. Worked for me!
Warning: I'm the only developer using the 17 repo. I cannot comment on the impact 16 of this hack on repo's with more users/complexity. Please 15 back everything up first.
After trying everything 14 in this thread an others I ended up deleting 13 the branch file from the remote server file 12 system located at \refs\heads\. I tried 11 deleting it from the local computer first 10 as Prateek suggested but that had no effect.
Ex. Lets 9 say my Repo is named "Foo" and my branch 8 is named "Bar". on System hosting the GIT 7 repo open the repo directory (Foo) and navigate 6 to the file "Foo\refs\heads\" Then rename 5 (eventually delete) the branch file named 4 Bar.
Git will recreate the branch file during 3 the push operation.
After the push, I switched 2 to master and merged the "Bar" branch without 1 issue
In the base directory of your local repo 8 you will find .git/refs/remotes/origin. In 7 this directory, your branch's namesake file 6 should contain the commit ID (40 alphanumeric 5 characters) of the latest commit of that 4 branch. If that is not the case, get the 3 last commit ID of your branch and update 2 the contents of the file. This fixed the 1 issue for me.
Raw, but the only solution that worked to 1 me:
- rename 'origin' remote with 'another name' and use that
More Related questions