Git unable to resolve references when pushing

Question

I am having an issue with Git. For unknown reasons, my master branch has somehow gotten corrupted. I have a local commit that I want to push up, but when I push, I get this:

git push origin master
error: unable to resolve reference refs/remotes/origin/master: No such file or directory
error: cannot lock the ref 'refs/remotes/origin/master'.
Everything up-to-date

I have seen the issue on other boards, but usually referring to pulls and not pushes. Nevertheless, I have tried their solutions, but to no avail:

1. Tried amending to my current commit and pushing
2. cleaned my git repository with git gc --prune=now
3. Tried rm .git/refs/removes/origin/master

None have solved my issues. Any thoughts or ideas?

Answer 1

Raw, but the only solution that worked to me:

• rename 'origin' remote with 'another name' and use that

Answer 2

In the base directory of your local repo you will find .git/refs/remotes/origin. In this directory, your branch's namesake file should contain the commit ID (40 alphanumeric characters) of the latest commit of that branch. If that is not the case, get the last commit ID of your branch and update the contents of the file. This fixed the issue for me.

Answer 3

Warning: I'm the only developer using the repo. I cannot comment on the impact of this hack on repo's with more users/complexity. Please back everything up first.

After trying everything in this thread an others I ended up deleting the branch file from the remote server file system located at \refs\heads\. I tried deleting it from the local computer first as Prateek suggested but that had no effect.

Ex. Lets say my Repo is named "Foo" and my branch is named "Bar". on System hosting the GIT repo open the repo directory (Foo) and navigate to the file "Foo\refs\heads\" Then rename (eventually delete) the branch file named Bar.

Git will recreate the branch file during the push operation.

After the push, I switched to master and merged the "Bar" branch without issue

Answer 4

The easy way to solve this is to first check if the git repository you are pushing your commits is getting updated with your commits or not. If yes then you can delete the cloned repository on your local machine and then again clone it. This way the error will go away. Worked for me!

Answer 5

Remove the following directory from .git folder -> .git/refs/remotes/origin

This will remove all the remote branches and you need to fetch them again using -> git fetch. This should fix the issue.

Answer 6

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 this git fetch --all.

now push or pull your code with,
this works for me,

Answer 7

rm .git/refs/remotes/origin/master

run git fetch --prune

Answer 8

I am probably a day late and a dollar short, but I recently experienced the same error message while setting up my first repository for school. I have looked at the answers above and none of them solved my problem. What did solve my problem was : sudo git push and entered admin password...

Answer 9

Note: with Git 2.5 (July 2015), git for-each-ref will be a bit more precise when it fails on a "missing object".

See commit 501cf47, commit f551707 (03 Jun 2015), and commit 8afc493, commit c3e23dc (02 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 file with invalid contents, "git for-each-ref" incorrectly reports the problem as being a missing object 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 can even report that the reference validly points at NULL_SHA1:

$ git for-each-ref --format='%(objectname) %(refname)'
0000000000000000000000000000000000000000 refs/heads/nonsense
$ echo $?
0

NULL_SHA1 is used to indicate an "invalid object name" throughout our code (and the code of other git implementations), so it is vastly more likely that an on-disk reference was set to this value due to a software bug than that NULL_SHA1 is the legitimate SHA-1 of an actual object.
Therefore, if a loose reference has the value NULL_SHA1, consider it to be broken.

Answer 10

(a worthwhile tl;dr from @NeTeInStEiN:

The nuclear option is rm -rf .git/refs/remotes/origin, and that's what it took here)

edit: I've run across part of this behavior in one of my own repos, I can get git to reproduce the f-e-r failure without the 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 warning, and git for-each-ref will fail with a familiar 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 tried with every setting of push.default, nor does it break git update-ref -d.

However, googling the push message 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 blow-by-blow, tl;dr is, because these were remote refs, which git fetch completely refreshes, and because the damage was such that for-each-ref and git update-ref failed to work at all, the nuclear option rm -rf refs/remotes/origin; git fetch was guaranteed to restore the remote properly.

In other circumstances, if there'd been no easy way to restore the damaged refs or for curiosity, find .git/refs/remotes/origin -type f to check for locks or using reflogs (those files are in .git/logs) to recover content would have helped but it wasn't necessary here. I think I missed a bet by not doing the find first, *.lock files from a kill -9ed earlier command look likely here, but I suspected an ambiguous ref and f-e-r is my first step for those.

---