Unable to unlink old file issue, puts repository in inconsistent state
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 2.3.1.0, and the file that cannot be unlinked is being tracked by LFS.
