nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

All comments

Steven A.

i see the same thing after i tookthe sourcetree update.

howellcc

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_q6feeq

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 C

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.

antonytm

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

emlynb

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.