[smt88]

I can't speak for before I started using Dropbox with git, but for the past 3 years, conflicts are handled well (and not as you describe).

First of all, Dropbox will not overwrite data. If it finds a conflict, it will save a second file with "[machine name]'s Conflicted Copy" and the modification date at the end.

This hasn't happened to me with any git files yet, however, because my machines are always online. That means my working tree is always the same across devices and my .git folder is always identical.

The only way a conflict would be created is if I committed while working offline and then committed on another machine while working offline.

If that happens, I could just grep my Dropbox folder for files with "conflicted" in the name and remove them. Or, because I committed my files to a remote (often Github, but sometimes others), I could just delete the local copy and clone.

[eli]

Sure, I'm not suggesting there would be permanent data loss... but doesn't Dropbox renaming a bunch of files deep within .git folder result in an unusable repository that you'd have to fix by hand or restore from backup?

[smt88]

This whole discussion made me curious, so I tested it. Dropbox doesn't rename files. It creates new files. All you have to do is delete the new files (which are really "forks" of your current data) and you have your working tree synced with your data store again. It's really easy.