Is it possible to host a bare Git repository using Dropbox, to share code?

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 folde

Answer 1

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 2

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 3

I'm pretty sure that this is unsafe. There's a bunch of moving parts in a Git repository, and Dropbox could easily wreck one of them. For example, you might end up with incorrect branch tips (master, etc.) in the refs directory, or your object store might stop working if the objects/info/packs file has the wrong contents. Git repos are fairly simple and robust, but they are not just dumb unbreakable storage.

Accessing remote repositories through SSH, git, or HTTP, or even locally on a network file system, is safe because the repository is only accessed through a git process, which makes sure that everything is moved into place in the right order. But Dropbox doesn't make any kind of guarantees about ordering, so you might lose data.

Just use a Git server (or any SSH server) instead -- if you don't have one, GitHub, Bitbucket or GitLab come to mind. It'll save you a lot of trouble, and it's no harder to use than a local repository shared through Dropbox (you just have SSH URLs instead of local paths).

Answer 4

I just host my repository on github.com as a private repository. Yes, you have to pay for a Micro plan ($7/plan) but you have the security knowing you have a backup of your code externally.

Answer 5

If I told you that there are cases in which Dropbox has screwed up my Git would I answer your question by contradiction? At least in my experience, this has happened more than 5 times and there are a lot of people having the same experience out there.

But nowadays I don't believe that Dropbox is really that essential with Git, really. Actually you can set remote branches (Github, Gitorious, Bitbucket) which can replace Dropbox sharing and revision history features (isn't all that about Dropbox?) and offer you even more.

Answer 6

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.