Show HN: Git-remote-dropbox – use Dropbox as a true Git server

I thought it gave you only 5 private repos?

Considering superior alternatives like mentioned BitBucket, I don't think I will use this project any time soon. But I'm very glad that some has created it. For me it demonstrates that git is flexible enough to support hosting/sharing solutions that are not standard today. I take it as a sign of git being a least a bit futureproof.

But aside from that, do all hacks have to be practical?

BitBucket has no 2FA, both GitHub and Dropbox do.

For small private repos, GitHub makes the per-GB price very high compared to Dropbox.

Well, it's from Atlassian for one :)

This could be useful as a backup.

I don't know about BitBucket, but GitHub has suffered downtime before. If you have a second remote on Dropbox, you can also get to your files there and wherever it's automatically syncing them should your VCS go down.

Also since packs are not used (the design document says it stores all objects as loose objects) there is no delta compression. This won't be usable for large repos with lots of history.

Yes, you're right, there is no garbage collection on the remote. (I should probably add that to the design doc.)

I don't know a way of doing it client side that is concurrency-safe. Perhaps I'll write a separate script that will do remote GC, but will require that you manually ensure that nobody is modifying the repository concurrently.

Some ideas...

- Mobile apps: ability to browse/create super easily from your iPhone or whatever using any app that integrates with Dropbox

- Storage space: though not always written in stone, most git hosts expect code and prefer you keep your media, if its heavy, elsewhere. Users of git-annex, largefile, etc. benefit from this.

- Collaboration: lots of people use Dropbox, not all of them need to use git (or at least, not all the time). See above.

Unfortunately, after reading the readme I see this: "Do not directly interact with Git repositories in your Dropbox folder - always use git-remote-dropbox. If you're using the Dropbox client to sync files, it's a good idea to use selective sync and disable syncing of the folder containing the repository to avoid any unexpected conflicts, just in case." So it's not as rosy as my above points hoped for.

For a few pennies more (or less) a month you can use AWS CodeCommit. https://aws.amazon.com/codecommit/pricing/

> If you're technical enough to understand git then you're technical enough to set up your own hosting server.

I don't agree. Many people use GIT without having any knowledge of the work necessary to keep a server secure all year around.

Amateur git usage is definitely a thing and not necessarily a small one.

I think it's mostly not dangerous. The object store shouldn't be dangerous at all. Updating refs concurrently however... I think it is dangerous.

That's what I use for my own projects. If I was working with other people I'd probably just setup gitlab (if not using github), with VPS providers these days setting something like that up is marginally more expensive than free.

Have you used DB for your repos where you work on different machines that are not always on, and therefore there is a sync delay occasionally? And then get conflicted syncs on DB's end as a result when you try to interact with the repo before syncing is done across all machines? There are many headaches to just putting a git repo in DB and forgetting about it -- the one possible exception if you are only working on one machine all the time, with zero collaborators.

This is a remote helper meant to interact with a git repo hosted on Dropbox - it runs entirely on the client side - there's no special git-specific code that the Dropbox servers run.

Correct, you're not expected to leave the working directory in a Dropbox folder. In fact, that's a bad idea (for the reasons explained in the blog post / readme).

It's also recommended to selective sync out the repository directory so the desktop client doesn't touch the files at all.

As anishathalye said you probably don't want to keep your git working directory on Dropbox. If you want to share a git working directory between machines, you can use a shared filesystem such as our ObjectiveFS (https://objectivefs.com). Note that if you use git with an OSXFUSE filesystem you currently need to add the "--quiet" option to work around an issue with signals (https://github.com/osxfuse/osxfuse/issues/213).

My point being, if there is such demand from your customers for a particular feature that they hack it together themselves, or endure what commenters have expressed to be "tolerable strange behavior", then you should probably think about offering a solution.

Is it right to host your git repositories in a Dropbox folder? Probably not. Is it their fault? No. Is there sufficient evidence that quite a few people are trying to do it? Yes: https://www.google.com/search?q=dropbox+git

Unless, of course, they've become too big to care.