Unable to create '/git/index.lock': File exists - but it doesn't

Question

I'm getting this message when trying to rebase interactively using source tree.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

fatal: Unable to create 'X:/sources/project/.git/index.lock': File exists.

The problem is that X:/sources/project/.git/index.lock doesn't exist

All the other solutions on SO didn't work for me since they all say to remove this file.

Answer 1

I'm on a Mac and ran into basically the same issue. When running git rebase -i master, I received an error:

fatal: Unable to create 'path/to/file/.git/index.lock': File exists.

The index.lock file didn't exist in my .git/ directory. But there was an index file (no filetype extension). So I aborted the rebase.

After a ton of searching, I finally decided to just create the file: touch .git/index.lock

I tried rebasing again, but that didn't fix the issue (this time the file really did exist). So I removed it: rm .git/index.lock

That did the trick. The rebase had conflicts this time (which was odd since I aborted the rebase previously), but I just addressed each conflict and then let the rebase continue: git rebase --continue

I hope this helps someone else who ends up in a similar situation.

Answer 2

Use rm -rf X:/sources/project/.git/index.lock to remove the lock and save yourself a headache. Also, the index.lock exists, however, the .git folder is hidden. So, use ls -la X:/sources/project/.git to see the content of a hidden folder.

Answer 3

I had the same issue using Github Desktop. I watched the .git directory and the index.LOCK file would appear and disappear. It never persisted for long, so was not there to delete. I investigated a little as other solutions online did not work for me and found that comparing permissions to folders that I was able to commit they had one difference: the .git folder that gave me the error had full control like the others, but it was inherited from its parent. I went to properties->security->advanced and removed then re-added the permissions without inheriting them from the parent. After that I was able to commit my changes without an error.