Git - " cannot lock ref is at " on git Pull

Question

I see the below error when i do git pull on my terminal in intellij. The project is constantly updated by several developers and i'm sure something is out of sync, but cannot figure out what that is.

error: cannot lock ref 'refs/remotes/origin/feature/SOMETHING-1234': is at e131d16d4b4b8c32e3d16d28559baf2e4d18b012 but expected 090916d9bee669944a2ea55703f25a4ebee7d51a
 ! 090916d9b..e131d16d4  feature/SOMETHING-1234 -> origin/feature/SOMETHING-1234  (unable to update local ref)

What could possibly be the issue here ? How do i fix this ? The feature branch above has been created by another developer i don't want to delete it.

Answer 1

Note: this is a duplicate, but the other question has no accepted answer, so I am posting one here. The problem occurs because someone created a branch (feature/SOMETHING-1234 in your example above) that differs only in case from a name that your Git already picked up. For instance, you might have feature/something-1234 or FEATURE/SOMETHING-1234, while they now have feature/SOMETHING-1234.

Git believes that names that differ only in case, such as a vs A, are different names. This works correctly some of the time. It fails on some operating systems¹some of the time. When it fails—as it is in your case—you get odd symptoms like the one you are seeing now.

In this case, one way to possibly cure it is to remove the (local) file .git/refs/remotes/origin/feature/something-1234—you can type it in in all-lower-case, regardless of whatever parts have upper-case; see footnote 1—just before you run git fetch. Your Git will re-create this with the case supplied by the other Git. Note, however, that the problem may well come back, perhaps even immediately, especially if the other Git is one that can store both names (e.g., both feature/something-1234 and feature/SOMETHING-1234) at all times.

To cure the problem more permanently, it is necessary to delete the duplicate-except-for-case name in the other Git. That is, if a GitHub Git has branches named both feature/SOMETHING-1234 and feature/something-1234, you and your colleagues must get together and agree on which of these two names to keep and which one to delete. Then you can and should delete the "wrong" one and make sure never to re-create it.

(There is ongoing work in Git that will fix this problem for everyone, I think, but it's not released yet.)

---

¹Technically, this is a file-system specific problem these days, rather than an OS-specific problem. However, it normally occurs on Windows and MacOS file systems, which are set up to be case-preserving but case-folding. That is, if you create a file named ReadMe, then ask the system to open a file named readme or README, it opens the existing ReadMe file.

Other file systems—including the usual ones used on Linux hosts, such as those running GitHub—treat readme, ReadMe, and README as three different files. So these systems can and will store all three files at the same time. The case-folding file systems on Windows and MacOS literally can't store three such files.

Git currently uses a hybrid scheme, in which refs or references—branch, tag, and other names—are stored in one or both of two places: a simple plain-text table file that has every reference on a line along with its hash ID, or, one hash ID per file, with the file's name matching the reference name. When the refs differ only in case, the per-file storage mechanism only works correctly on file systems that can store both names. The one-big-file mechanism works correctly even on the usual Windows and MacOS file system, though, as all the entries are just in a file named .git/packed-refs.

Note that if a ref appears in both .git/packed-refs and an individual file, the individual file version overrides the .git/packed-refs version.