+1 for bitbucket.

I've used dropbox+git for sometime [1]. It throws "conflicted copy" error [2] when two people push to origin at the same time. Bitbucket much better than dropbox, but not as awesome as github.

[1] Shorter version - http://stackoverflow.com/a/1961515/45582

[2] http://shikii.net/blog/ignoring-funny-ref-error-on-git-dropb...

+1 for bitbucket.org. The free private repos for up to 5 folks is awesome (for git and hg/mercurial). Very stable, never had any issues.

If you have an e-mail address in .edu you can have free private repos with unlimited users having access to them. Just register your .edu e-mail on the site and the 5 user limit is removed.

I also wonder why so many people forget about bitbucket. To me really it's the matter of taste, and there is certainly less differences between github and bitbucket than there is between git and mercurial.

I managed to convert a few Github paying customers to switch to bitbucket. The only reason they state for using github was that they didn't know bitbucket is available for use with git (as well as with mercurial) besides the private repos thingy.

AFAIK thanks to the hashing used with git there is very little chance of corruption. The filenames are 32bit hashes so the probability of collision between the hashes of two given files is 1 / 2^32. The probability of collisions between any of N given files is (N - 1) / 2^32.

I meant a state that the repo does not like and not really corrupted. say you push your changes and someone else pushes their changes and you both try to move the head and you get a dropbox conflict. You would have to go and fuss with the refs and the refs log to find out where the other head should have gone and manually change things that you shouldn't have to. Not the end of the world but for a guide that is seemingly for beginners why hassle with it when there is a free way that is easier to do what they are trying to accomplish?

Repo "corruption" via dropbox does not need a SHA-1 collision.

Git uses other files for tracking things, for example: .git/refs/* and .git/HEAD, which point to particular objects (via SHA-1 hashes). If one of these has a "confilicted change" (via dropbox), one person has the HEAD of the repo (or some other branch) pointing to a commit they do not expect it to point to. Even more interesting is when one person wins HEAD and the other wins it's paired branch in .git/refs/ .

Further, git does occasional packing of the object repository. 2 People attempting to pack the object repository when it contains different items might produce interesting results.

Just to correct you: the probability is _much_ bigger than (N-1)/2^32.

See the birthday problem: http://en.wikipedia.org/wiki/Birthday_problem

The search space of the object name is a sha1 and is 40 characters long and not 32 bits so it's quite a bit larger than the op was talking about(it's actually 160bits).

see: http://book.git-scm.com/1_the_git_object_model.html