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 18.104.22.168, and the file that cannot be unlinked is being tracked by LFS.
Supported Platforms macOS Windows To make using Sourcetree as simple yet powerful as possible we embed (bundle) dependencies such as Git, Git LFS, and Mercurial. We strive to keep these...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs