Is this plain stupid: GIT Sharing Via DropBox?

Question

I realize that there are similar questions, but my question is slightly different. I'm wondering whether sharing a bare repository via a synchronized DropBox folder on multiple computers would work for sharing code via GIT. Really what I want to know is: is sharing a GIT repo via DropBox (the repo gets updated on each person's local drive) the same as sharing it from one centralized location, e.g., via SSH, git or HTTP?

Is this the same or different from sharing a GIT repo via a shared network drive?

Note: This is not an empirical question: it seems to work fine. I'm asking whether the way a GIT repo is structured is compatible with this way of sharing.

EDIT To clarify/repeat, I'm talking about keeping the GIT repository on DropBox as a bare repository. I'm not talking about keeping the actual files that are under source control in DropBox.

Answer 1

I used to do this with MobileMe, but the computers kept getting out of sync. Each computer would have a repo that was different than the one in the cloud and since there's no concept of "merge" in MobileMe (and I assume, DropBox, too, right?) I'd end up just having to either pick a version to keep and lose some edits, or copy the edits out and re-apply them. Life has gotten a whole lot easier since I switched to a central Git repo.

If it's working for you so far, good. I imagine you're going to have a lot of pain if two devs push to their local bare repos at the same time, though. How's DropBox going to know which is right?

Answer 2

I see no reason why it would lose data -- Git's repository structure is robust, and in the repository store itself, files with the same name will always have the same content (this doesn't apply to branch names).

It's not going to be efficient, though. Git's transfer protocol means that it will usually only transfer a change once. With Dropbox, if two people pack slightly different repositories, the packs generated may contain significant common data while not being identical, so DropBox would sync both packs, which is inefficient.

You may also find that, although the data is all there, you wind up with un-tracked changes due to two copies both having the same branch updated at the same time. This can be worked around by ensuring that you push to different branches from each copy, but it'd be a pain.

Answer 3

What happens if two users are disconnected, do some work, push to their local copy of the bare repository and then go on line? In this case, when Dropbox tries to synchronize you'll get problems -- pack files and branch tips will be different and Dropbox can't fix that. That's the only problem I could see. I think the same thing could happen even if both users are connected, if they happen to be pushing into their local bare repositories at the same time.

Answer 4

One problem with DropBox has to do with how they handle historical backups. While you can roll back an individual file (within the last 30 days, or forever if you have PackRat), you cannot roll back entire directories. This means that if your repo gets screwed up for any reason, the amazing service of having a historical backup is essentially useless, since you would have to click on thousands of files to bring them back to an earlier version.

And then there are the problems with race conditions, if you will, mentioned by most of the other answers.

Answer 5

I've had problems with using Dropbox with Git and with Mercurial. Repository files often get corrupted, presumably due to Dropbox's synching not being perfect, particularly when changes are being made from multiple places. Also, Dropbox works in the background, so it is really easy to accidentally try to use the repository (or reboot your machine) while it is in the middle of a sync operation.

I love Dropbox, but it is not a good replacement for a shared drive or a "real" remote Git repository.