Can Dropbox handle git repostories? ONLY as a secondary backup?

[mind_over_machine]

Hello, 

I have a script that copies my git repositories into Dropbox every 10  minutes.  It only copies modified files.

This includes .git subfolders folders as well as my code files.

In total this is a 6 Gb directory with around 20,000 files.

Is this okay?

To be clear,  I am not not hosting a .git repository on Dropbox, nor am I pushing to it or using it as a remote.

I am not working inside the dropbox folder.

It is PURELY for backup purposes of the state of my local project in the event of system crashes, drive failure, and power outages.

Is this okay? I am concerned because of somewhat related posts on here, github, and stack exchange that indicate Dropbox may corrupt files inside the .git folder???

However previous posters are trying to use .git / work from INSIDE dropbox.

I am not trying to do that. But I DO have to paste in the .git folder, every 10 minutes.

Is this okay?

Again, I am not directly working out of dropbox locally nor am I  trying to use Dropbox as a remote repository.

I am not collaborating with anyone either.

No one will touch these files or run any git operations INSIDE dropbox. 

I am using a FreeFilesync batch script to copy into dropbox files that have changed from a different directory. (Similar to robocopy or rsync on unix). 

Looking on this forum,  I am still concerned that Dropbox may STILL corrupt .git files? It could zero out files? Ignore dot files? Corrupt repository data? 

But is this true even for a simple backup job such as mine?

Can someone Technical Support / Engineering or anyone that uses a similar workflow please confirm?

In summary: Is it okay to do automated 10 minute copy/paste backups of GIT repositories into Dropbox?

Only updating files that changed. Please confirm????

Thank you!

[Megan]

Hi @mind_over_machine, thanks for posting here! 

Keep in mind, that once the file is copied into Dropbox then the only thing left from there is to sync the file.

It shouldn't be a problem really. In some cases, it might just be best to pause or close the app and just allow for the content to sync and backup. Since doing it every 10 mins might have an issue if they're large files. (for example: it starts syncing a change/addition and then another file is added or a file is edited before the initial one finishes syncing)

If you have any questions, let me know!

[mind_over_machine]

Thanks Megan!
Yeah I totally understand,  I can set a longer delay and allow Dropbox to catch up. 

Was just concerned about the integrity of .git subfolder syncing correctly on your end.

Whew.

[Mark R.96 · Accepted solution]

For GitHub + Dropbox + Git:

If your priority is worktree syncing between your own machines, while using a remote repository (e.g. github):

I solved my problem by forcing Dropbox to ignore my .git subfolders.

That syncs my personal worktrees, while leaving github alone. Be careful about how it works though, and only do it only for your own account (e.g. your own PC and your own laptop). I simply have to re-pull from my other machine (directly from github) when I push from one machine, to make sure that the git data is in sync with each other.

It behaves as if you copied over the files manually via thumbdrive (excluding .git), so make sure you re-pull git everytime you switch machines. And always remember to switch branches on both machines manually, every time you switch branches.

Instructions for Windows (run in PowerShell):

Set-Content -Path 'C:\path-to-project-inside-dropbox\.git' -Stream com.dropbox.ignored -Value 1

Instructions for Mac:

xattr -w com.dropbox.ignored 1 /path-to-project-inside-dropbox/.git

Instructions for Linux:

attr -s com.dropbox.ignored -V 1 /path-to-project-inside-dropbox/.git

It's convenient when you have a lot of data/logs/object files/etc (anything big in .gitignore but you let sync in Dropbox, as LAN sync is fast enough to sync the big stuff).

Dropbox syncing all the data and object files allows faster compiles of larger projects on both owned machines after minor modifications (for same-OS x64), and easier comparative testing on the other machine.

And keeps github unpolluted.

This is better than the selective sync system because of all the automatic "selective sync conflicts". This method forces Dropbox to completely ignore everything in specific subfolders, as if it didn't exist.

And if you mess up, you also have a double backup of github and Dropbox to rewind to (both have separate convenient recovery use cases, like resurrecting specific logfiles).

Note: There are many variations on (less safe) Dropbox+Git workflows. Some people use a separate side workflow to sync .git folders (preferably via git pull sanctioned methods, but some people manually copy the folder over after pausing development temporarily on both machines).  Another workflow is to temporarily pause the dropbox process automatically before a bunch of git commands ("pssuspend Dropbox" to pause Dropbox, and "pssuspend -r Dropbox" to resume Dropbox) but that is still riskier than this workflow.  I simply mention this as an additional alternative, that is more appropriate to certain single-developer use cases. Such workflows is not typically recommended for multiple-developer repositories, as corruption can happen.