Why git pull fails?

Question

Today, supposingly I faced with a git problem. It's 1 year I use git (just push and pull commands) and all been fine so far. But today this command doesn't work and throws an error:

$ git pull origin master

Here is the error:

Does anybody know what's the problem and how can I fix it?

score 3 · Answer 1 · edited May 23 '17 at 12:10

check this question on StackOverflow that resolved the same error:

Git and nasty "error: cannot lock existing info/refs fatal"

To quote the accepted answer:

This happened to me when my git remote (bitbucket.org) changed their IP address. The quick fix was to remove and re-add the remote, then everything worked as expected. If you're not familiar with how to remove and re-add a remote in git, here are the steps: Copy the SSH git URL of your existing remote. You can print it to the terminal using this command:
git remote -v
which will print out something like this:
origin git@server-address.org:account-name/repo-name.git (fetch)
origin git@server-address.org:account-name/repo-name.git (push)
Remove the remote from your local git repo:
git remote rm origin
Add the remote back to your local repo:
git remote add origin git@server-address.org:account-name/repo-name.git

score 2 · Accepted Answer · edited May 23 '17 at 12:02

2

Check if you have a master file in .git\refs\remotes\origin

If you do, delete it, then try your git pull again.

As an alternative, simply try and clone again your repository in another folder just to see if the error persists.

As torek mentions in the comments

the string "reference broken" means that the indicated ref name exists, it just has an invalid SHA-1 hash ID attached to it.
That's not supposed to happen (the ref name itself should have been destroyed by now), so it's not clear how this came about.

You can see the error message in refs/files-backend.c#lock_raw_ref()

if (errno == EINVAL && (*type & REF_ISBROKEN)) {
            strbuf_addf(err, "unable to resolve reference '%s': "
"reference broken", refname);

That check was introduced in Git 2.10 (April 2016) which mentioned:

This makes use of a new function, lock_raw_ref(), which is analogous to read_raw_ref(), but acquires a lock on the reference before reading it.

This change still has two problems:

There are redundant read_ref_full() reference lookups.

It is still possible to get incorrect reflogs for symbolic references if there is a concurrent update by another process, since the old_oid of a symref is determined before the lock on the pointed-to ref is held.

edited May 23 '17 at 12:02

Community

1
1

answered Apr 29 '17 at 05:18

VonC

1,129,465
480
4,036
4,755

@MartinAJ yes, if Git needs it, it will recreate it – VonC Apr 29 '17 at 05:20
ok, but I ask again, are you *sure* ? My codes are valuable to me. I never can write them again `:-(` – Martin AJ Apr 29 '17 at 05:21
@MartinAJ removing the file is just removing a reference, it does not alter your existing codebase. That being said, to be *really* on the safe side, simply make an archive (a zip) of your current local repo folder if you want. – VonC Apr 29 '17 at 05:22
FWIW, the string "reference broken" means that the indicated ref name exists, it just has an invalid SHA-1 hash ID attached to it. That's not supposed to happen (the ref name itself should have been destroyed by now), so it's not clear how this came about. – torek Apr 29 '17 at 06:44
@torek Thank you. I have included your comment in the answer for more visibility. – VonC Apr 29 '17 at 07:04

Why git pull fails?

2 Answers2