Why is Google Drive deleting my Git files?

Question

I use a local Git repository (no remote version) for my personal projects. Everything gets synced to Google Drive, including Git files and directories.

Yesterday I noticed that two classes had disappeared from my working copy. I used Git checkout to retrieve them. Today, three classes (files) disappeared and my Git repo was corrupted, so git status would say there was no repository there. I noticed that Google Drive was syncing about 30,000 files, mostly deleting files from that directory. I paused and checked my Recycle Bin, where I found a bunch of Git files. Restoring them returned my Git repository, which I used to hard reset to HEAD and get the lost classes/files back.

Has anyone had this experience with local Git repos getting synced to cloud storage and found a solution? I don't understand why Google Drive should decide to purge my files, especially Git files.

Answer 1

You should never synchronize git or any other dvcs repository using any such synchronization tools.

This includes git, mercurial, fossil, bazaar, etc.

For synchronization tools this includes Dropbox, Google Drive, OneDrive, Jottacloud, etc.

Why?

Because these tools doesn't consider the repository as a unit, they consider the individual files inside on a file-by-file basis.

Here's an example of how you can easily mess up your repositories:

1. On one computer you commit a new changeset
2. You then move over to another computer
3. Before or while this has completely synchronized your changes you start doing commits or other operations
4. Then the synchronization kicks in and in some cases will get conflicts

How conflicts are handled varies but for some of them an extra file is created with a "-conflict" filename. Git or any other of the tools won't look at this conflicting file. If both files was renamed you have now corrupted your repository.

The biggest source of problems this kind of situation could create is when modifications done on separate computers are mixed. Conflict files would be created but depending on the order of things you might have 4 files that have changed on one computer and then the same 4 files changed on another, however due to the synchronization, ordering, and conflicts, you end up with 2 of them from the first computer and the other 2 from the other computer. The unity of these modifications belonging together has been lost.

Note that conflicts here should not arise in the git objects as these should be uniquely named (SHA1) and only be added, but any of the housekeeping files that keep track of branch pointers and such will easily get into a conflict.

This kind of corruption might be fixable after the fact but it might be difficult and a lot of work and would most likely involve a good working knowledge of the Git internal datastructures.

Exactly why you experienced the thing you experienced, and why those files were deleted is next to impossible to answer.

However, there is a very easy fix for this whole thing.

Stop using Google Drive to synchronize your repository and sign up for a free bitbucket account instead. Push your repository to a private project/repository up in the cloud and simply use normal push/pull operations between your computers.

Answer 2

The chosen answer above is right in that it is a risky and incorrect thing to do in general. However, in practice, if we're talking about a working copy that only a single person is using it can be useful in some situations. I sometimes put a working copy of a project into google drive when I'm bouncing back and forth between my desktop and laptop and experimenting a lot. I still end up pushing any changes to the real repo, which is not in google drive, so there isn't much danger of losing anything other than a little time if I had a conflict and that hasn't happened to me yet at all.

By the way - You can access a git repository on any machine that is accessible to you via ssh. You do not have to set up a git server or do any special setup. Just clone the repo over ssh, e.g. git clone mymachine:/path/to/repo and subsequent pushes and pulls will work as expected.