SourceTree repeatedly losing track of index.lock

[Simon Watson]

Every time I try to make a change in my branch, SourceTree creates an index.lock file in the .git directory, then refuses to make the change because an index.lock file exists. Deleting the lock file doesn't help, as SourceTree will just create it again. Any suggestions?

[Steven A.]

i see the same thing after i tookthe sourcetree update.

[Clinton Howell]

Ditto.  Let me know if anyone finds a solution.

[Gil Shapir]

Ditto - same exact issue.

[Wayne Tan]

Still a problem in v1.9.6.2, especially interactive rebase. Please vote on this issue to get someone working on it: https://jira.atlassian.com/browse/SRCTREEWIN-5639

[Giancarlo Berner]

I just did an update to 2.6.3 and the index.lock issue is back again! It seems that Sourcetree creates the index.lock, then does the commit or whatever task you trigger, and at the end does not delete index.lock anymore. I manually have to delete index.lock every time I trigger an action. When will this be fixed?

[Thomas Vogelpohl]

I have the same issue with 2.6.3. 

It is annoying to delete index.lock by hand after every activity.

[swendrich]

Same here with 2.7. That really sucks! Atlassian please fix it. That would save my x-mas days.

[Dune Casu]

Getting this in v2.4.7.0 on Win10. 

Edit: It started working again right after I posted this so I think it's an intermittent issue.

[anton tishchenko]

Getting this in v2.4.7.0 on Win10 time to time.
SourceTree creates and removes git.lock file repeatedly. 

[Emlyn Bolton]

I still see this on 2.7.1 on macOS very regularly. I think it's a race condition somewhere in source tree as sometimes it causes it and sometimes it can sort itself out.

I have had success with closing sourctree and deleting .git/index.lock from the command line

[Mikel Kew]

I'm also seeing this VERY frequently in 2.7.6 (macOS 10.12.6). Has being occurring intermittently for quite a few versions now. Seems to be most common for me when the system is under high CPU load from other processes.