> We can perform a compare-and-swap operation in Dropbox by using the "update" write mode with a specific revision number.
Since a Git repository basically consists of a hash-addressed content object store alongside a mutable list of references (mapping branch names to hashes of latest commits), you need a compare-and-swap operation on the reference list to update the branch reference when you push new commits. The Dropbox client by design does not do a compare-and-swap whenever a file is updated, but the Dropbox API supports it.
The official docs cover it pretty well:
If it's for your own use, you can skip the part about creating a `git` user, and host the files in eg `/home/$USER/repositories` instead. The repository setup instructions remain the same, just the path differs, and the `authorized_keys` file to add keys to will be in `/home/$USER` instead of `/home/git`.
On the server:
mkdir project.git; cd project.git
git init --bare
git add remote newserver email@example.com:project.git
git push newserver master
why doesn't OP use bit-bucket ?
I wish they would fix their Github syncing (they can currently do it, but don't tell you their public SSH key so you can add it to Github as a pushing/pulling key).
The only first world probem I have with Gogs is when you change branch deep into a directory it goes back to the top level view.
Just a heads-up to anyone planning to use Gogs for large repos: Gogs is basically unusable for large repositories( such as the git repository itself and the linux kernel). The response times through the web UI can extend into a few minutes on small servers( I tried it with a 2 cpu and 2GB RAM server on DigitalOcean) and even on extremely powerful servers, the response times for large repositories is almost the same( I tried it on a 8 cpu and 16GB AM server). The reason for this is that Gogs lacks a cache system for git repos. You can follow the issue here.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8cBZzV5gblDfbi41AxXC3fmfP8w1okfdNn9b6uXaj7i03NwhJ0n4Eg8Z+zgAtyrIa2bw9tzF8fyeYsnRbK5Paj059dn+XiXp3HOgcvHO9jy9C1+nomkRCM55fkMSGyiSByh2KSOiqqAusrTV9joig/Re30gYpxm8iCs20gbD717lZTT0A3dnrv7IQ86nbn9+5h+yMcok/AWEWS6Xq1NJGG5vav+vh+Nhlteo72qj77B/DFK1noUxcTgcy27xZOp1wrr7a6PaBu6wEMgKd2Oe9wQtzycaOYTAywHqtXnOE/w7FvhJen20GqtL9k4Zr94hxUNG7LJoiO6gNzo/0q24t firstname.lastname@example.org
Using the key they placed on my Bitbucket repo worked on one of my Github repos.
EDIT: Turns out that key doesn't work. How can I make them add a key to my BitBucket account? I don't see an option for that...
For that, you might consider using something like git-remote-gcrypt, which encrypts data client-side before sending to the server.
It looks like this is no longer the case:
I haven't been able to determine if they're still storing the git repositories on NFS:
but if that's the case, I would be extremely nervous about the integrity and stability of their platform. I've had too many bad experiences with NFS mounts failing and general instability that I don't want to deploy it anymore.
We're still on NFS but are looking into Ceph https://gitlab.com/gitlab-com/operations/issues/1
Edit: Apparently I was beat to the punch ;)
Of course, just using Gitlab is the more sensible option :)
[EDIT] - as lfowles pointed out, github doesn't private repos on free-tier accounts, so this is pointless.
But since I am a ghetto peasant without a static IP address I prefer to keep everything in what the cool kids call "The Cloud".
I assume you're running your own VPS with gogits/gogs running on it?
> There seem to be some articles on the Internet suggesting that this is a good idea. It's not. Using the desktop client to sync a bare Git repository is not safe. Concurrent changes or delays in syncing can result in a corrupted Git repository.
How dangerous would this be in practice? Ie, what are the chances of corrupting a git repo with this method with a small team, and what exactly must happen to cause it?
A HN discussion from a few years ago suggests that Dropbox + GIT is a mixed bag: https://news.ycombinator.com/item?id=5558822
There are occasional conflicted copies (once every few months), but it's rare and I don't recall encountering one in quite some time (months).
* Don't work on things concurrently
* It's brittle (like any sync service) if you're editing things when that folder is still updating. This is especially so when it comes to git.
* Repositories with lots of small files take a long time to sync.
Edit: Wow I got downvoted and I actually ran the experiments myself. Has anyone got experiments showing otherwise?
> 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.
Also, in case this wasn't obvious, this is basically a "shim" to use dropbox as a git server (as opposed to say mercurial or SVN). No actual git server is being run and if I understand correctly, some useful features from a normal git server are not implemented.
> git-remote-dropbox is a Git remote helper.
> git-remote-dropbox stores all objects as loose objects - it does not pack objects. This means that we do not perform delta compression. In addition, we do not perform garbage collection of dangling objects.
but this project exists exactly because of this and circumvents said problem.
I've another hackish method that's good enough for a single developer, plus it's encrypted.
I've got a truecrypt file container that resides in Dropbox. I mount it as read-write when I want to push. On the rest of my machines, its mounted as read-only. Even if the container is 100GB, it takes 10 seconds to sync daily commits - because of block encryption & syncing. This won't work with Google / MS / Amazon drive etc. because they upload the entire container on each incremental change.
Truecrypt uses XTS mode, which is Not Great -- it only exists because someone was trying to hammer ciphers into fitting nicely with fixed sized disk sectors, and it makes a number of serious compromises to do so.  has a good discussion of this. You do not want to combine XTS with sharing multiple versions of the ciphertext.
tl;dr you've seen the penguin pictures? As  cleverly says, you're pretty much doing that to yourself by sharing multiple versions of the file.
There's also significantly more powerful attacks that can be mounted by an adversary that can feed you corrupted blocks which will allow them to permanently compromise your key, or perform other hijinks like manipulating your content without setting off warning bells. Dropbox, or someone that compromises dropbox, is in that position, by nature of the service they're providing. These issues are rooted in the fact that XTS is not an authenticated cipher -- this leads to such an endemic category of subtle problems that it's been nicknamed "The Cryptographic Doom Principle" .
So yeah. If your life depends on it... don't store a truecrypt volume in dropbox.
 I found a mirror at http://andryou.com/truecrypt/docs/how-to-back-up-securely.ph... -- and I'll quote, in case that too vanishes:
> IMPORTANT: If you store the backup volume in any location that
> an adversary can repeatedly access (for example, on a device kept
> in a bank’s safe deposit box), you should repeat all of the above
> steps (including the step 1) each time you want to back up the
At a first glance at the design docs here, the present project looks more sophisticated in terms of syncing. I'm just using local file operations and hoping for dropbox to do its stuff :)
I use Syncthing to sync around my personal git repo between my machines. All pushes and pulls are instant. I don't have conflicts because I'm only working on one machine at a time. `git-remote-syncthing` would presumably be even better, allowing multiple simultaneous users.