SourceTree keeps deleting every file from a mounted repository and stages the change

I am using SourceTree to manage a git local repository mounted from another system. SourceTree seems to have problem with it. Whenever it couldn't connect to the mounted folder, it thinks all the files are deleted and stages all the deletions. I have to undo the staged change all the time, which is very annoying. Is there a fix for this problem?

7 answers

Git is designed so you would have an actual local repository, and treat the repository on the other system as a remote. Is there a good reason why you can't do this?

my local repository is on a shared linux box in a data center somewhere. I won't be able to compile and test my code on my local machine. I am just mounting the repository to my Mac so that i can use sourceTree to manage the git repository. My guess is that sourceTree is not designed for this scenario.

gitX doesn't seem to have the same issue, though. However, gitX is not as powerful as sourceTree.

"On a shared linux box in a data center somwhere" - that is, by definition, not local.

The "correct" solution would be to set up a Git server on that linux box, and clone it.

A faster solution would be to clone the locally-mounted repository instead of using it directly. In SourceTree, hit "Clone/New", and put the path to the mounted repository in the "Clone Repository" tab instead of "Add Working Copy". This will copy the repository to your local drives, and allow you to push and pull from the shared box. Plus you get the added bonus of being able to work on the code without a network connection.

The remote machine is our dev machine, we create our local repositories (off a central repository somewhere else) there and work on it remotely because all the libraries and environment settings are there. Code checked out from the remote machine won't run or build locally. And we also use a ssh terminal or a remotely loaded Eclipse instance to edit the code on the dev machine. We do rely on the network connection to work with our code.

Cloning another repository off the mounted "local respository" will add another step in my workflow. That is, edit the code locally on my mac, commit it locally. Push the commit to the dev machine repository. Test the code on the dev machine and then push it to the central respository.

This might be a use case sourceTree doesn't cover at this point. But i guess the fix might be simple, if the entire repository can't be found in the mounted file system, don't do anything to it in sourceTree until the repository can be found again.

I am in a similar situation where my code isn't runnable on my local instance. I keep my repository local and SFTP files to the server as needed for building/testing. I don't find the workflow to be a burden, and I find the reliability of local file access far outweighs the inconvenience of the extra deployment step.

If my solution still doesn't work for you, that's fine. Atlassian may push a fix to SourceTree to be more reliable with your type of setup, but I don't think there's anything you can do about it right now.

Hello,

Hope it's OK to comment on a thread that is nearly a year old, but I am having this exact issue with SourceTree. Our code is stored in an ubuntu VM on our Mac, but SourceTree is continually staging all files as removed. It is really making it nearly unworkable. 

Has anyone come up with a solution for this that doesn't involve using 2 git repositories, one locally and one in the VM as having to commit, push and pull every little change is not really a solution for development.

Having 2 git repositories, one locally and one in the VM, is exactly how Git is designed to work. I don't mean to sound dismissive - I can definitely empathize with the convenience of being able to use local software to manage a remote repository, but the git client (or UIs that simply wrap the git client) aren't going to cut it. You might try the GitX software that Jiang Wu mentioned. Maybe it will make an SSH connection to issue git commands on a remote server. Alternatively, if the VM is local, you might try sharing the opposite way. In other words, make the machine with SourceTree the real home for the files, and then mount them to the VM.

Is there any solution to it? It seems to be something Source Tree related.

I think it is. Our team ended up moving to Tower. Haven't had the issue since. To give SourceTree credit, it might not have happened if we were using a proper mount. Instead we are using sshfs

That's bad news. I'm also using sshfs. Source Tree is a great tool but I'll give Tower a try. I hope they can fix this in the near future.

Suggest an answer

Log in or Join to answer
Community showcase
Brian Ganninger
Published Jan 23, 2018 in Sourcetree

Tip from the team: workflow and keyboard shortcuts

Supported Platforms macOS Sourcetree has a lot to offer and, like many developer tools, finding and using it all can be a challenge, especially for a new user. Everyone might not love ...

274 views 0 3
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot