-
Suggestion
-
Resolution: Won't Fix
-
None
-
None
-
Win7
I've recently encountered this problem:
git -c diff.mnemonicprefix=false -c core.quotepath=false checkout – source/VersionInfo.cs
fatal: Unable to create 'C:/Projects/xyz/.git/index.lock': File exists.
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.
Just not to blame SourceTree : It wasn't his fault 
But I would like to have a little helper button: "Delete index.lock" or "Free lock" or even a Force option might be helpful. Everything I want is remaining in the UI of SourceTree and don't open the stupid Console typing this: >del .git\index.lock.
Can youo help me?
Thanks
Marcel
[SRCTREEWIN-1130] "Force option" if index.lock exists or "Delete index.lock" option
Craig Muckleston
added a comment - I get this every time I try to switch features. Very annoying. This issue makes sourcetree unusable for me. I'm forced to switch using a different tool because of this annoying bug.
Sampsa Lehtonen
added a comment - I get the index.lock issue multiple times a day when I double-click the branch name in the list in order to check it out. I've tried to chase it down, and it seems that this status git command runs just before the checkout:
git.exe --no-pager -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false status --porcelain --ignore-submodules=dirty --untracked-files=all
Then, under 200 milliseconds later the checkout command kicks in while that status command is still performing - and failing because of the index.lock being in use:
git.exe --no-pager -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false checkout master
Then 700 milliseconds later the first command is done, releasing the lock. That's why you get the error and when you go and look, the index.lock is not there.
In the screenshot PID 800 is the status command, and PID 10700 is the checkout.
Please Atlassian, fix this. Maybe make sure that no two git commands are being invoked simultaneously or something?
It's driving me crazy! Also, use Sysinternal Procmon when developing desktop apps, you'd be amazed what you'll learn about your app 
Sampsa Lehtonen
added a comment - I get the index.lock issue multiple times a day when I double-click the branch name in the list in order to check it out. I've tried to chase it down, and it seems that this status git command runs just before the checkout:
git.exe --no-pager -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false status --porcelain --ignore-submodules=dirty --untracked-files=all
Then, under 200 milliseconds later the checkout command kicks in while that status command is still performing - and failing because of the index.lock being in use:
git.exe --no-pager -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false checkout master
Then 700 milliseconds later the first command is done, releasing the lock. That's why you get the error and when you go and look, the index.lock is not there.
In the screenshot PID 800 is the status command, and PID 10700 is the checkout.
Please Atlassian, fix this. Maybe make sure that no two git commands are being invoked simultaneously or something?
It's driving me crazy! Also, use Sysinternal Procmon when developing desktop apps, you'd be amazed what you'll learn about your app Just thought I'd mention this here as it's been my go-to workaround for a while now. For me, I mostly experience this issue when switching branches by double-clicking on the branch that I want to switch to. But I've found if I right click on that same branch and select "checkout", sourcetree will proceed to switch to that branch as expected, without error.
Just my observation, and my work around. Hope this helps.
William Jones
added a comment - I have the same issue. I would like some sort of indicator that the lock file is still present, it would save me from having to close the error and reclick (which is usually all that it takes...)
William Jones
added a comment - I have the same issue. I would like some sort of indicator that the lock file is still present, it would save me from having to close the error and reclick (which is usually all that it takes...) 
Tim Petermann
added a comment - Having the same issue as Robert, Daniel, and Clinton since updating to git 2.5.
Tim Petermann
added a comment - Having the same issue as Robert, Daniel, and Clinton since updating to git 2.5. 
use rm -f ./.git/index.lock