use rm -f ./.git/index.lock

I get this every time I try to switch features. Very annoying.

Wow guys, fix this bug. That's really annoying. Makes ST unusable

Won't Fix? very nice, thanks. this makes ST unusable.

Same here, happens to me 90% of the time when I am squashing commits

This issue makes sourcetree unusable for me. I'm forced to switch using a different tool because of this annoying bug.

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

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...)

Having the same issue as Robert, Daniel, and Clinton since updating to git 2.5.

Seeing this constantly (many times a day) since using Git 2.5.3 for Windows.

I'm experiencing this as well and quite frequently. When I switch branches and when attempting to merge 1 branch with another. The index.lock file is never there when I look.

Win 8.1
Sourcetree 1.6.2
System Git 2.5.1

Installed 2.5.2 and noticed several times the same error comes, but not subsequently (meaning, when the same branch is tried to be co-d after the error, it works).

What i also noticed is that an artifact was created in working copy during that branch switching (a <name>.jar was coppied as <name>-0.jar). That file was not there before (in neither of the branches) nor it was in the working copy/staging. Maybe something to keep an eye out for...

With Git 2.5 this happens a lot if you try to change the branch by double clicking the branch name, but that doesn't seem to be the problem that is adressed in this ticket.

As a workaround it helped me a lot to update to git for windows 2.5.2.2 and if the problem occurs use the right click option "Checkout <branch>...". Seems to be releated to some timing issues, but is defenitely not worth discussing in this ticket.

Hapens to me regulary with 2.5 Git. Can't checkout a branch from SourceTree anymore. And, what's worst, there is no index.lock file at all!

I also encounter the same issue frequently with version 1.6.11
The index.lock file can be generated after trying to pull the changes from remote repository to local, while the changes to be pulled conflicts with local commits.

Hi there
I actually have this issue ALL the time.
Basically every 2 or 3 commit+push I have to manually delete this file and this is obviously very annoying
Sourcetree is my only GIT client
I also never use GIT from the command line so I'm not sure what's wrong
I'm using the embedded version of GIT (build 1.8.3) and don't have a system one installed
In case it can help I'm under win7
Thanks in advance
Stephane

Yeah unless it starts to become really common I think this isn't something we'll put in, deleting files like this is potentially dangerous if git changes something in the way it works etc so I'd rather not.

No, it isn't really common. Nevertheless it might be a helpful feature for everyone who has other Git apps in place. I mean those ones who tend to crash sometimes

Setting this feature to Trivial or even close it would be fine if I'm the only guy who faces this problem.
Thanks anyway
Marcel

I'm not sure it's really common enough to have an explicit feature for it, do you get this a lot? I can't remember ever seeing it.