Hi, I'm having some issues with the way SourceTree is handling files that are being updated in a pull, but are currently in use on the computer.
I have a number of developers who will often be running a program that will lock a resource we have in git. When using SourceTree to pull this resource, I get this error (screenshot attached).
When this happens, the repository will be in a mixed state. Some files that were successfully pulled before getting to the locked resource will be treated as if they are unstaged changes to those files. When closing the program holding the file lock and attempting to pull, those unstages changes get in the way and must be discarded before being able to pull. If the files are new then they must be deleted before being able to pull.
This is a pretty awful situation to get into as some developers are not comfortable with cleaning out the files of these changes before being able to update.
This behaviour is coming from SourceTree. If I execute the pull from the command line or using Tortoise CVS, I am provided with an option to retry on the file.
Closing the program with the lock on the file and retrying successfully completes the pull. Cancelling instead of retrying reverts the repository to the state before the pull. These are great results from this situation, and it would be so much better if SourceTree to do the same.
Just for more information, I'm using SourceTree 184.108.40.206, and the file that cannot be unlinked is being tracked by LFS.
A vulnerability has been published today in regards to Sourcetree for Windows. The goal of this article is to give you a summary of information we have gathered from Atlassian Community as a st...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events