desktop: "fatal: Could not write a new index file" on Windows 10
Description
I get this error when attempting to commit. I can start from scratch with a new clone of an entire repo, but it eventually comes back again.
It’s happened with various repositories, and on my previous Windows 7 Ultimate installation.
I’ve tried to delete the .git/index file, but then it shows that all the files in my repo are brand new. That’s not going to work.
If I restore an older version of the .git/index file, I still get the same error on committing.
My workaround each time has been to start over from scratch, cloning the github.com repo down to my machine, and re-implementing all the changes I had made since my last successful commit and push.
I additionally find I often need to uninstall and reinstall GitHub Desktop to get it to commit without error.
Version
- GitHub Desktop for Windows 1.4.3 64 bit
- Operating system: Windows 10 Pro
Additional Information
Logs
2018-10-30T15:58:29.041Z - info: [ui] Background fetch for 3 repositories took 2.028sec
2018-10-30T16:02:09.254Z - info: [ui] Executing fetch: git -c credential.helper= fetch --progress --prune origin (took 3.395s)
2018-10-30T16:13:30.883Z - info: [ui] Background fetch for 3 repositories took 1.837sec
2018-10-30T16:18:07.639Z - info: [ui] [AppStore] loading 3 repositories from store
2018-10-30T16:18:07.641Z - info: [ui] [AppStore] found account: MarkerB (Mark Bernard)
2018-10-30T16:18:08.096Z - info: [ui] launching: 1.4.3 (Windows 10.0.16299)
2018-10-30T16:18:08.097Z - info: [ui] execPath: ‘C:\Users\mark\AppData\Local\GitHubDesktop\app-1.4.3\GitHubDesktop.exe’
2018-10-30T16:18:09.081Z - info: [ui] Executing installGlobalLFSFilter: git lfs install --skip-repo (took 1.137s)
2018-10-30T16:18:16.401Z - error: [ui] git reset -- . exited with an unexpected code: 128.
Unstaged changes after reset:
M xxxxxxx_archive.php
M functions/xxx/xxxmisc.php
fatal: Could not write new index file.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 16 (6 by maintainers)
I had the same issue but my solution was to close my VS Code program (I had the GitHub Repo loaded in the side panel). I guess it ties up the GitHub Desktop and causes this type of issue.
It’s probably not that simple. It seems more likely it’s just an unfortunate interaction between GitHub and Google and creative methods they use to keep track of things.
Oh, yes. So far, so good. It was an intermittent problem, so I wanted to give it a little more of a test.
Google Backup and Sync may have been locking the git index file when it saw the file updated, locking it long enough to upload it to the cloud. Maybe GitHub Desktop needed the file more freely accessible than that.
Since Google Backup and Sync doesn’t allow exclusion by folder, I had to put my git repo in a completely separate folder.
Thank you so much! This had been a real problem for me in the last week; not sure why it came and went. Timing.