$ git --version --build-options
** insert your machine's response here **
``` 2.12.2.windows.2
- Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
$ cmd.exe /c ver
* insert your machine's response here *
Microsoft Windows [Version 10.0.14393]
- What options did you set as part of the installation? Or did you choose the
defaults?
defaults
type "C:\Program Files\Git\etc\install-options.txt"
type "C:\Program Files (x86)\Git\etc\install-options.txt"
type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
* insert your machine's response here *
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
- Any other interesting things about your environment that might be related
to the issue you're seeing?
** insert your response here **
### Details
- Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
** insert your response here **
Bash
- What commands did you run to trigger this issue? If you can provide a
[Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve)
this will help us understand the issue.
* insert your commands here *
```git add .
* insert here *
files to be added
* insert here *
fatal: Unable to create 'C:/Users/admin/.git/index.lock': File exists.
* insert URL here *
Sometimes Git crashes or is killed by the user (see ctrl+C) and an index.lock file gets left behind.
Are there no more git.exe process running? The simply delete the file at C:/Users/admin/.git/index.lock and carry on.
I have the same issue but only intermittently using either git stash or git rebase.
If I go to the folder after the command fails the file index.lock does not exist.
It's looks like the command is creating that file deleting it but not fast enough so later in the execution it git believe that this file already exists.
When this happens I usually have only one terminal running git but maybe some editors are also calling git (VS or VSCode)
I'm using git version 2.12.2.windows.1 on Microsoft Windows [Version 10.0.14393]
Below is a repro with GIT_TRACE=1
> git rebase --skip
13:52:17.782437 git.c:596 trace: exec: 'git-rebase' '--skip'
13:52:17.782936 run-command.c:369 trace: run_command: 'git-rebase' '--skip'
13:52:18.442436 git.c:371 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--skip'
13:52:18.729523 git.c:371 trace: built-in: git 'rev-parse' '--git-dir'
13:52:18.957049 git.c:371 trace: built-in: git 'rev-parse' '--git-path' 'objects'
13:52:19.087546 git.c:371 trace: built-in: git 'rev-parse' '--is-bare-repository'
13:52:19.217022 git.c:371 trace: built-in: git 'rev-parse' '--show-toplevel'
13:52:19.395216 git.c:371 trace: built-in: git 'config' '--bool' 'rebase.stat'
13:52:19.570215 git.c:371 trace: built-in: git 'config' '--bool' 'rebase.autostash'
13:52:19.721691 git.c:371 trace: built-in: git 'config' '--bool' 'rebase.autosquash'
13:52:19.850721 git.c:371 trace: built-in: git 'config' '--bool' 'commit.gpgsign'
13:52:22.793110 git.c:371 trace: built-in: git 'am' '--skip' '--resolvemsg=
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
'
fatal: Unable to create '***/.git/index.lock': File exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
For what it's worth, I had the issue quite consistently and deactivating fscache solved the issue (for now)
git config core.fscache false
For what it's worth, I had the issue quite consistently and deactivating fscache solved the issue (for now)
Very odd as fscache is in-memory only. No idea how that would impact index.lock other than make everything slow, and thus avoid racy conditions.
When this happens I usually have only one terminal running git but maybe some editors are also calling git (VS or VSCode)
I'd look at these other tools to see if they're touching the index at the same time as you're performing another command. I think that's the most likely answer for what's happening here.
Closing this out as expected behaviour of Git.
Most helpful comment
Sometimes Git crashes or is killed by the user (see ctrl+C) and an index.lock file gets left behind.
Are there no more git.exe process running? The simply delete the file at
C:/Users/admin/.git/index.lockand carry on.