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

[Jiang Wu]

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?

[Rodrigo]

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.

[Scott O_Connell]

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

[Rodrigo]

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

[Seth]

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.

[Scott O_Connell]

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.

[Seth]

"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.

[Jiang Wu]

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.

[Seth]

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.

[Seth]

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?

[Jiang Wu]

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.

[Jiang Wu]

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