git problem : fatal: Unable to write new index file_问答_开发者

I have an existing project that has been managed under git. I recently had to do a ground-up rebuild of the computer (OS X Snow Leopard), and returning to the project, git can track the changes in the project, but I can't save anything to git. I get the error in the title when I try :

Dans-iMac-335:[app-name-obscured] apple$ git add app/models/*
fatal: Unable to write new index file

What's the best way to recover from this situation? There is a heroku repository version of this, but it is very out of sync with this one. presumably I could use a new clone as 开发者_Python百科a basis, and update each file, but that seems over laborious and error prone.

What is git looking for here that it can't find, and is there a change that will restore it?

BTW, file permissions are correct from what I can tell - the files under control and the .git components are both owned by me with rw access...

I just ran into the same situation, it turned out that my filesystem was full.

Do you have write access to .git (=can you create new files there and edit existing ones)? If not then adjust the file permissions.

If you have write permissions it seems you found a bug. You can try to recover by

create a clone from your current working copy
remove all files from the working copy of the clone
copy all wc files from your current working copy to the clone (and don't copy .git)
try to commit something in the clone.

When the last step works you need setup the remote branches from your current repo to the clone, and then you can use the cloned repo as your new working copy.

I was using Parallels running Ubuntu on my Mac. I could git init, but not git add. I believe the issue is that git add requires an atomic synch to the underlying git database. And since the filesystem I was using was actually on my Mac and Parallels was exporting from my Mac via a network share. I believe this means that git couldn't do what it wanted. Moving the files locally fixed the problem (In my case this was easy since I was using DropBox on my Mac, so I just installed DropBox on my Ubuntu running Parallels)

I've had a simular problem with SFTP Network Drive (free). The solution is: fill chekcbox "Delete existing target before moving" found in the Profile Settings of SFTP Network Drive.

I was able to fix this by going into the .git folder in the git initiated app and deleting the index.lock/index file. I had to reindex the entire app, but it resolved the problem.

If you are using sshfs, add the option -o workaround=rename, as described here: http://alan.lamielle.net/2009/07/08/git-over-sshfs

I'd like to point out one more cause of this error

If you are cloning a git repository that contains another git repository in it (not submodule), you will get this behaviour.

Hope it'll help somebody.

I had same problem. I still dunno the cause, but my workaround is delete index.lock sudo rm -f index.lock, and then i gave write permission to index sudo chmod 777 index. After this I am able to stage and commit. The problem is I have to do this almost all the times I have something to stage.

This is old, but the cause for me was Dropbox. My local repository was stored in my Dropbox folder, and I had to pause Dropbox syncing before I could complete the command.

I had a similar problem. "git reset --hard" worked for me.

To add: surprisingly, some git plug-ins blocks index file. My Eclipse Kepler has default plug-in, that occasionally updates some own info from git repo, blocking index file during that operation.

I had used this problem when using git on visual studio, and my solution was to run visual studio as an administrator

I had the same error because Google Drive's Backup and Sync client for Windows had not released a lock on two files within this repository. A work around was, after the sync client had finished its work: Process Explorer -> Find -> Find handle or DLL -> Close Handle.

I had the same problem. "fatal: Unable to write new index file"

I found out that the reason was that my disk was full. I removed something else from it and then my git repo recovered and all worked again.