0

This is one for all the folks who truly grok version control.

So there's a bunch of people out there saying "if you put a github-managed repo in a dropbox folder, your world will end." Dave Winer, for example, reports unspecified disastrous results. This SO answer suggests that dropbox has the potential of corrupting git repos wherever hosted because of cross-OS encoding problems, various answers here report or speculate about numerous problems, there's a comment on this SO with similar warnings, everyone answering here agrees, also here, here etc.

Here's the thing. I really really want to use github and dropbox together anyway, and for one simple reason: dropbox is my first-level backup solution. (Not my only backup solution, of course, but my first level one.) If I suffer a hard drive crash, I'm confident that I could get everything I truly need right off dropbox... everything, that is, except stuff under git version control, which I push to github.

So, it strikes me that there's a really easy way around the risks that everyone else has identified, one that presumably doesn't bear any risks of repo corruption. Run a cron job (on, in my case, a mac, but I assume this would work equally well under linux, a vanilla bsd, etc), like nightly or even hourly, that just copies everything in folders holding repos under git to a dropbox folder and cleans up the previous version.

I assume that this wouldn't pose any danger to the underlying git repos, because I assume that whatever dark magic git does when it watches files for changes isn't also watching for files to be copied elsewhere. But I don't have any actual evidence for that assumption, because my git-fu isn't anywhere near where it needs to be. (Hence my characterization of the thing as "dark magic.")

But you, dear reader, have git-fu far more advanced than I do, and can tell me: would this kind of maneuver successfully keep anything dropbox does to the copied files from interfering with what git does to the files in the original locations?

Community
  • 1
  • 1
Paul Gowder
  • 2,409
  • 1
  • 21
  • 36
  • Probably not. The issues come down to the differing ways your OS handles line endings, not the fact that Dropbox syncs as you update files. – AlbertEngelB Dec 10 '15 at 21:19

1 Answers1

0

I'm not sure if this is what you're looking for, but Git is perfectly happy to push to a local URL.

What I'd suggest doing is setting up a remote in your primary repository that points to a secondary bare repository that is stored in your local view of the Dropbox.

This way, you have somewhere for your cron job to push to, and you get all the transactional benefits that go along with using a push instead of just an ordinary file copy:

git init --bare /my/dropbox/path/secondaryrepo
cd /path/to/primaryrepo; git remote add dropbox /my/dropbox/path/secondaryrepo

Then your Cron script can just run:

git push dropbox master

The files wouldn't be checked out in the secondary repository, so Dropbox can't futz about with them directly. All you'd have is the .git folder containing the objects and metadata. I can't guarantee that it won't do something funky, but I think git objects are essentially an append-only filesystem. I could be wrong about that! Git Internals might be a good place to start for more info. :D

grw
  • 1,279
  • 1
  • 11
  • 19