[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)
• run git fetch --prune in 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 git fetch]

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 for-each-ref and 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 find first, *.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.

1. just go to this dir. in your project and delete the origin folder from your project:

.git/refs/remotes/origin

2. now just run this commannd:

git fetch --prune

or you may fetch all your branches by using 2 this git fetch --all.

now push or 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 (mhagger).
^{(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_SHA1 is 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_SHA1 is the legitimate SHA-1 of 1 an actual object.
Therefore, if a loose reference has the value NULL_SHA1, consider it to be broken.

rm .git/refs/remotes/origin/master

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