The beauty of Git in Dropbox | Hacker News Reader

The beauty of Git in Dropbox

I have been debating with friends about the power of git merged to the simplicity of Dropbox.

Hear me out. I can see a very cool feature when using git within a dropbox folder.

Imagine you are working on several computers (one at home, one at work, one laptop). With git, you can (obviously) pull to get the latest version of your branch on all your devices. But if you put your git repo on dropbox, you just fire your laptop on and your project will be up to date !

What do you think about this workflow ? Would you do this ? Do you see any problems with this usage ? I would love to hear more.

View on HN

This has been discussed before as a bad idea. Unless Dropbox has improved, you'd likely run into syncing issues like I did 6 months ago.

On the other hand, the top voted answer on this SO question demonstrates how one might use a Dropbox directory as a git remote, so that you can push code there intermittently, preventing the trouble with constant writes to the Dropbox.

http://stackoverflow.com/questions/1960799/using-git-and-dro...

I don't understand. Were you trying to put your repository and your working directory in Dropbox? That does, indeed, sound like a very bad idea.

Putting just `.git` in Dropbox seems like it would be fine, though.

Bonus: If you create bare repository in public you can clone(read-only) it with ease from anywhere.

That's exactly what I do - "remote" repository in dropbox and push/pull in a "local" copy in my home folder. Works just fine for sharing code between my own PCs. I use it only for my personal projects, sharing repos this way is just asking for repo corruption -- if you both push at the same time, say goodbye to your repo.

This is not a good idea. Dropbox has its own notion of how to resolve conflicts, while git spreads its repository over several files; if you commit from two machines at the same time it is entirely plausible it will corrupt your repository. If your only goal is to have your git repository "autopull" it'd be pretty easy, and much safer, to script that

I have for about a year now done all my work out of Dropbox (via a symlink from ~/src) it works great for multiple machines and has added advantages, eg. I never worry about deleting files that aren't staged anymore, as I can undo the delete from Dropbox’s website.

Git is for long-term version control, working out of Dropbox is like having a script running that stashes and unstashes every change you make so that its in the git-reflog.

I also do this, it's a great workflow I think.

There are occasionally conflicts, but I've never actually gotten a corrupted repository. All I ever do is go with the latest version of things using 'find' to delete the conflicts.

I've been doing something similar for the last couple of years (SVN and Ubuntu One rather than Git and Dropbox). In general it works very well but you need to ensure that both computers have properly synced before you switch working between them or you risk issues with conflicts and/or corrupted files. Also you should have a backup plan in case things go wrong. In my setup I only keep the working copy in Ubuntu One with the repo somewhere safer. This means if something doesn't work properly I can simply create a new working copy. I realise Git works a little differently but it is always worth ensuring you can recover from failure as Dropbox and equivalents are all slightly less reliable than traditional file storage. The final thing to bear in mind is that if this is for work, some employers will be unhappy about their proprietary code being hosted on the "cloud" rather than on computers they control.

I've created bare git repositories on Dropbox before and haven't had any problems using them as git remotes. They've only been used by me though, so things might get more tricky if you need multi-user access.

A few have mentioned syncing issues, so if you try the Dropbox approach, think about what the worst that could happen might be? If you can live with that, then give it a go. You can always setup other git remotes for GitHub and / or Bitbucket as well, in addition to a Dropbox remote, if you worried about syncing issues (although you'd obviously have to manually push / pull to these).

When you save to Dropbox, you're just saving to your local machine. Then the Dropbox app pushes the changes to the Dropbox server. When you wake up or turn on another authorized computer, the Dropbox app on that machine polls the Dropbox server, and pulls the changes.

Conceptually, it's the same as using a hosted git remote repo, like Github. The only thing it saves you is having to type the git push and pull commands...not a huge savings IMO.

Besides that, the only advantage I can see is that the Dropbox process is private by default, whereas Github repos are public unless you pay.

You might also be interested in SparkleShare which replicates the functionality of Dropbox using Git http://sparkleshare.org/

I keep my personal repos in Dropbox (then my working directory elsewhere) - I still have to push and pull when switching computers (and make sure Dropbox syncs), but it's worked out fairly well for me. You can share the Dropbox folder as a sort of poor man's private Github repo, but you need some sort of out-of-band communication to ensure that you don't push to it simultaneously.

Have you seen http://git-annex.branchable.com/?

I use a similar workflow with SVN to great effect. I have never had a sync issue - whether this is luck or that the repository structure is more robust in this setting than Git's, I don't know. I would strongly recommend against using this as a collaboration tool, though!

I find that as long as you save files and make sure dropbox is "synced" before starting work on another machine, this setup works fantastically. I occasionally have Dropbox "conflict" files, but have never had an issue figuring out which versions to keep.

I've used Mercurial over Dropbox before and would caution against it. Somehow the repository got corrupted (I'm betting on a bad Dropbox sync) and then all the repositories got corrupted. Since then moved to bitbucket.

I used this approach for my class projects a couple of years ago. It served the purpose pretty well. I used github to mainly collaborate with others while dropbox to use on different(lab/home) machines of mine.

Sounds quite an interesting idea... make a git client that acts like dropbox.

The convergence of dropbox and git was some of the initial inspiration for http://projectmeadow.com .

I already successfully use this method between my work laptop (Windows 7) and my home laptop (Ubuntu 11.04) and haven't run into any problems yet!

I do exactly that (syncing multiple computers with my work-in-progress files and data) with bitbucket.org.

Not sure why would i need to add dropbox to equation?

It is also worth noting that Dropbox saves its own revision history automatically, just like Google Docs.

Only with Pro + Packrat:

Packrat is a Dropbox Pro add-on feature that saves your file history indefinitely.

Dropbox saves a history of all deleted and earlier versions of files for 30 days for all Dropbox accounts by default. If you have the Packrat add-on, Dropbox saves those files for as long as you have the Packrat add-on. With Packrat, you never have to worry about losing an old version of a file.

https://www.dropbox.com/help/113/en

I do this for several years with lots of repos. Not a single problem ever.

And I use different OSes – Mac OS X, Windows 7 and XP, sometimes different git versions. And still no problems.

So you never see conflict messages or conflicted files in your Dropbox? In the few cases I've tried a git working copy on Dropbox -- which is what I believe the author is discussing -- I've had conflicts.

For example:

    $ ls -1 .git/index*

    index
    index (blacktip.esquimaux.org's conflicted copy 2013-04-09)
    index (hammerhead's conflicted copy 2012-01-30)
    index (holodeck's conflicted copy 2012-01-26 (1))
    index (holodeck's conflicted copy 2012-01-26)
    index (holodeck's conflicted copy 2013-04-09)

It was only the index file and not anything irreplaceable (not that git does a lot of mutating of files in general). But it rapidly ended my experiment with git on Dropbox.

I used to see conflicts all the time

I ran into this too. It was annoying enough that I ended up just using bitbucket.

I'm confused, how is this better than just using github or bitbucket?

Basically you don't have to pull anymore. An example of what happens to me every day: My laptop is connected to Internet all day long, and I work on my computer iMac. I keep pushing about every hour, and when the day is over, I just close my laptop and can go on working in the train (no Internet there).

If I hadn't been using Dropbox, before leaving work, I would have to pull, and sometimes I just don't have time.

(This is one example out of many)

Use a similar approach, except with Mercurial. It works. :)

I've been doing this exact setup for over a year now. I sync between three computers: office desktop, home desktop, and laptop (all three computers run Ubuntu 12.04). I'm very happy with this setup, although there have been problems.

The major benefit is that I don't have to remember to commit and push my changes before switching from one computer to another. When I'm leaving work, I'm often in a hurry; when I get home, all of my work comes with me. Same thing applies to travelling with my laptop.

The major problem is that Dropbox occasionally fails. Because I have come to rely heavily upon this setup, a failure causes significant pain. In my experience, Dropbox has failed in 2 ways.

1. I make some changes on computer A. Dropbox screws up when syncing the change to computer B. When I switch to computer B, I discover that the repository on computer B is messed up (HEAD has been updated, but not the working tree; or the local repository is messed up so that 'git status' fails; or something else bizarre). In this situation I must switch back to computer A, move the 'good' repository outside of Dropbox, wait for Dropbox sync to complete, move the repository back into Dropbox, wait for sync to complete, then finally switch back to computer B and wait for Dropbox sync to complete. You can imagine how this process would be extra painful when it requires you to commute back and forth between home and office for each step.

2. I make some changes on computer A. Dropbox has silently stopped syncing the repository on computer A. When I switch to computer B, I discover that none of the changes made on computer A have synced. In this situation, restarting Computer A usually causes the Dropbox sync to resume. Troubleshooting this situation follows a similar course to situation 1.

I have communicated with Dropbox support extensively about Situation 2, and I believe that it is related to the '10,000 folder limit' for Dropbox on Linux. See the section "Monitoring more than 10000 folders" on this page:

https://www.dropbox.com/help/145/en

Git uses a very large number of folders (usually around 1500) for each repository. This does not play well with Dropbox on Linux. When Situation 2 occurs, Dropbox gives every indication that it is working correctly; files that are not syncing show the "green checkmark", and the Dropbox tray icon shows "All files up to date". Troubleshooting Situation 2 was a thoroughly enraging experience.

A good precaution is to push your personal working branch to GitHub (or your remote repository of choice) as a backup when using this setup. Treat this remote branch as disposable; if you rebase your working branch, you can just delete the remote branch and push your rebased branch (`git push origin :my-working-branch`, `git push origin my-working-branch`).

So, there have been some serious issues, but altogether I am very happy with my setup. I like the flexibility of not having to commit and push changes when I'm switching from one computer to another, and in general I feel the daily benefits have outweighed the occasional problems.

Reply on news.ycombinator.com