7

I love to use Google Drive for Desktop. I love to put everything in the cloud since centralizing everything makes things organized.

However, is a Git directory dangerous to be in such syncing drive?

Definition of dangerous:

  1. Inconsistency of ".git" with "all tracking files". (sync tool may change .git with its tracking file at different times, which may result in disaster when you commit something or push something.

  2. All other possible side effects of letting the sync tool change the .git

Gino Mempin
  • 25,369
  • 29
  • 96
  • 135
Luk Aron
  • 1,235
  • 11
  • 34
  • 1
    Why aren't you storing your repositories on github? If you are *really* intent on using google drive, you can use [`git-archive`](https://git-scm.com/docs/git-archive) to generate a tarball which you can then store in drive in a "safe" way – joshmeranda Sep 04 '21 at 14:10
  • thanks for the advice, but the question should be answerable even without knowing the intent, it is just asking what it is. – Luk Aron Sep 04 '21 at 14:17
  • 3
    Unless Google Drive or Git indicate that they are compatible, I would assume that it is dangerous and your data will be corrupted. It's the only safe answer. – Jonathon Reinhart Sep 04 '21 at 14:19
  • 2
    Note that "the cloud" just means "someone else's computer, over which I have no control". If they damage your data, what will you do? If they take their computer off line, what will you do? Admittedly this "someone else's computer" is convenient, and most of them are really very reliable, but always remember, it's just someone else's computer! – torek Sep 04 '21 at 18:24

2 Answers2

12

I love to put everything in the cloud since centralize everything makes things organized.

Personally, I generally avoid folder-sync services or cloud hosted folders (like OneDrive, Google Drive, DropBox, etc) because they all strive to give users a simple and easy to use experience, which is impossible to do given that the CAP theorem certainly applies to folder-syncing services: so these services' general refusal to let their users have detailed conflict resolution tools - as well as their inability to track changes like splitting-up of files, or even cloned files (looking at you, OneDrive...) just causes headaches.

Is it dangerous to put git directory in drive sync tool

Yes

But it's also moot, because git is already a tool (and entire ecosystem) for keeping repos in sync: just exclude your repos from Google Drive and host your repos with GitHub, BitBucket, or your own self-hosted git server off your NAS or so.

As for why it's dangerous:

  • The main reason is that git's tooling assumes it has exclusive access to your repo's .git directory and that other software won't be peeking at the files while git is working on them.
    • While git does use OS-provided file-locks and other IPC means to ensure exclusive access to its files, third-party folder synchronization software won't be respecting git's own IPC locks.
    • Also consider the wider scope of third-party git tools (GitKraken, Visual Studio's git integration, TortoiseGit, etc) of which we cannot be sure are "safe", as well as users' own shell-scripts for automating git that very likely won't have any kind of locking either.
  • Sync software generally uses features like copy-on-write and shadow-copies to be able to take snapshot copies of locked-files.
    • For example, since Windows 7 (maybe Vista?) Windows' File Explorer uses shadow-copies when you copy-and-paste a file that has an exclusive-lock held by another process.
    • ...which means that while your local .git directory might be in a valid state, the copy of the .git directory held by the sync service may be in a corrupt state (so don't restore it!) because (as far as I know) no third-party folder sync services attempt to make a transactionally-correct snapshot copy of a .git directory.

inconsistency of .git with "all tracking files". (sync tool may change .git with its tracking file at different times, which may result in disaster when you commit something or push something.

Sort-of. As I said, the risk is that when the sync tool is making a copy of your local repo then the sync services' remote-copy of your folder may contain an inconsistent copy of your .git directory where problems won't be apparent until after you subsequently download your folder from Google Drive or DropBox.

all other possible side effects of letting the sync tool change the .git

Too many to mention. Just don't let it happen.

This popular QA features people claiming they got their Git repos working with DropBox, however the highly-upvoted comments warn that their approach won't scale beyond single users (and you should not share a git repo anyway).

Dai
  • 141,631
  • 28
  • 261
  • 374
  • Git isn't an appropriate comparison as it's not automatic. If you're the only dev on a project and have to push and pull between, say, a laptop and desktop it's a giant PITA because there are often issues and even if not, you have to remember to push on the one machine which may not be with you now. Syncing with Dropbox or Drive, say, just saves you a lot of time. Of course this would only be for single users, but MANY projects only have a single dev, and if more join you can just stop doing this. This saves time, and time is money. – niico Jul 25 '23 at 13:08
  • @niico None of what you’ve said there addresses the non-transaction-safe file corruption problems inherent in using folder-sync software. – Dai Jul 25 '23 at 23:31
  • I'm not sure exactly what you mean, but issues are unlikely if you consider a single user is unlikely to have changed code on both machines without syncing. In addition if you have a backup program such as Backblaze with version history also running you can recover previous file versions or look at both and merge yourself. I've been doing this for a while and have had zero issues but saved a TON of time. – niico Jul 26 '23 at 16:29
  • \*sigh\* - no, you don’t understand the issues I’m talking about here. This has nothing to do with multi-user scenarios and all about how file systems are not transaction safe. – Dai Jul 27 '23 at 00:29
  • OK can you give me a practical example of why this would cause a problem for code repos more than other types of file? Millions of people use file syncing programs every day, few have issues. – niico Jul 28 '23 at 06:36
0

This has progressed, though not improved, since 2013.

There is a way, in Linux and MacOS, to mount the Google Drive as a remote partition.

From the answers I saw: a shared partition is not how GIT currently works. I was able to put stuff into a mounted S3 bucket via IDrive E2, they have a 10GB free tier. For micro collaborations like a Freelance.com project this could be fine.

My try, on Crostini or Google Colab shell commands to start a GIT repo:

mkdir /mnt/chromeos/GoogleDrive/MyDrive/git_repo
git clone --bare . /mnt/chromeos/GoogleDrive/MyDrive/git_repo/project_root_dir_name.git

Getting files on another Crostini host or from another Colab notebook. This command brings the files to target from mounted GIT repo.

git clone /mnt/chromeos/GoogleDrive/MyDrive/git_repo/project_root_dir_name.git

The path to Google Drive mount can be different from /mnt/chromeos/GoogleDrive/MyDrive. git pull, git push, git add, git commit can also be used, results will vary.

Not sure why using Google API directly need to be involved, there is a solution involving OCAML library to make a remote/shared file system mount point that a git repo can be stored in. Google Drive files have versions and pins and such, this is not a speed improvement for GIT. Deleted files go into trash.

Full GIT functionality:

Really not sure how Git would resolve a push synchronization conflicts if two or more guys pushed simultaneously. From answers I saw while researching, using a shared partition for git is a no-no. Looks like Google Drive would absolutely fail at file system hosting for a Git repo. I point to pins, revision history and trash can.

Main need to know: if more time passes (tick tock goes the clock), does a hosted file system git repo get corrupted if there are no network trouble? Certainly Google Drive consistency is not quick, once repo is modified you might have to give it a minute after the push.

In short, S3FS is a better workhorse than Google Drive for a Git remote. But, client system would need S3FS installed, this install might needs sudo privileges. Google Drive has a convenience of being available on crostini Linux [Chrome OS] without sudo installs.

Thanks.

Eric Aya
  • 69,473
  • 35
  • 181
  • 253
Yevgeny Streltsov
  • 11
  • 2