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

8

21

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?

In other words: is sharing a Git repo via Dropbox the same as sharing it from one centralized location, for example, via SSH or HTTP?

Does the repo get updated on each person's local drive? Is this the same as 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.

Connate answered 4/2, 2010 at 12:34 Comment(4)
DropBox doesn't have any sort of version control: whichever computer has the newest shared file, that file is pushed onto all the other computers. That's the only issue that would bother me in such setup.Alyosha
@Piskvor, fixed the question, hope it's clearer.Connate
Lots of duplicates: stackoverflow.com/questions/tagged/git+dropboxBeria
@jleedev, yes, but few of them predate this one :)Connate
P
15

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).

Partan answered 18/2, 2011 at 17:18 Comment(2)
Github has constraints (must be open source or you must pay), but Unfuddled (for instance) does not. But yeah, point taken about the dropbox.Connate
@Yar Thanks for the tip with Unfuddle; I've updated my answer. :)Partan
M
20

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.

Munsey answered 4/2, 2010 at 12:52 Comment(7)
Andrew thanks for that, +1. The untracked changes due to two people working on the same branch at the same time is the kind of thing I wanted to know about.Connate
you mean that if two devs chose the same branch name there would be conflicts?Connate
Yes, the commit referencing the current tip of the branch is stored in a file under refs. If two devs push to the same branch without a sync, both sets of commits will be stored, but only one will be referenced.Munsey
Okay, that makes sense, thanks. I in fact had to find some commits that were not in any branch this week, so I know that it's possible, but not ideal..Connate
@andrew-aylett - Wonder what you think of this scenario. We have our Git repo stored on our Windows network (the powers that be, don't want our code public, yet we are small enough that we are hoping to not pay for a hosting service when not really deemed necessary). Currently, if we want to push/pull to the bare repo, we VPN and do appropriate action. Was thinking we could put repo in dropbox, so that we have the repos duplicated on our box for fast (non-vpn required) pulls. But we always have to VPN to do a push and always only push to the one location. This would avoid conflicts right?Ez
@Terry: That should probably be a different question... I don't see that you'd get problems from Dropbox, apart from the delay in syncing, but you might still lose some of Git's efficiency, as Dropbox has no knowledge about what the data means.Munsey
I'm really curious, how have you all dealt with issues of clobbering each others' code? And how is this different than putting a clone of the repo on a shared network drive and telling everyone to work off of the network drive (which, btw, seems to more or less defeat the purpose of distributed version control)?Kasey
P
15

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).

Partan answered 18/2, 2011 at 17:18 Comment(2)
Github has constraints (must be open source or you must pay), but Unfuddled (for instance) does not. But yeah, point taken about the dropbox.Connate
@Yar Thanks for the tip with Unfuddle; I've updated my answer. :)Partan
C
12

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.

Carcass answered 4/2, 2010 at 14:37 Comment(2)
Thanks Pat, that seems to be the concern. So basically, while my DropBox strategy is great for backup, for sharing it's essentially useless due to these offline-online problems.Connate
The good news is that there's lots of free Git hosts out there and it's nearly trivial to set up a central repository if there's a server you all have SSH access to.Acid
G
9

I've had problems 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.

Garvy answered 16/7, 2010 at 14:40 Comment(1)
Yes. Especially when unfuddle (and a lot of others) give you (small) repos for free. Thanks for your answer.Connate
A
5

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?

Acid answered 4/2, 2010 at 12:47 Comment(5)
That's the question. I thought that, due to hashes, there is never any conflict... ?Connate
I don't see how the computer could get out of sync. Obviously you would have to push and pull from the MobileMe repoConnate
Check out @Andrew's response, that's the kind of thing I was referring too. All your objects should sync with no conflicts, because of the hashes, but any files not named with hashes could cause conflicts. At least with MobileMe, conflict resolution is minimal.Acid
Same with DB I would guess. How would it resolve binary file conflict, anyway?Connate
I did it with timestamps, which usually meant one set of changes either had to be discarded or manually re-applied. It didn't happen that often, but it was a pain.Acid
T
3

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.

Transom answered 29/9, 2012 at 20:8 Comment(1)
Actually using git with files that are in Dropbox will result in sync problems, unless you work on just one computer.Connate
C
2

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.

Connate answered 8/5, 2010 at 10:35 Comment(0)
C
0

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.

Chesty answered 17/2, 2011 at 8:47 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.