[dr4g0n]

Looks good, I had previously used Dropbox for personal repositories, but now I might try using them for shared ones.

It seems from a quick read of the design document [1] that the important thing here is the updating of refs using a compare-and-swap, ensuring that the synchronisation issues that typically occur with using Dropbox as a remote cannot occur. Objects are always* safe from this since the file names are SHA1 hashes.

Edit: The only downside I can see with this is that the remote will never have garbage collection take place, so unreachable objects will continue to take up space indefinitely.

[1]: https://github.com/anishathalye/git-remote-dropbox/blob/mast...

[anishathalye]

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.

[phs2501]

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.

[anishathalye]

Yep, no packing and no delta compression. I haven't yet thought of a good way of doing that entirely client side. (If you can think of anything, please let me know!)

The target use case is small personal and group projects.

With the current design, it won't scale that well to large repos with lots of history. The initial clone will take a while. However, individual fetches or pushes after that shouldn't take that long unless there is a ton that changes.