4 ms·

If you are already trusting a cloud service with your data why not go one step further and use bitbucket for free private repos? You don't have the possibility

If you are already trusting a cloud service with your data why not go one step further and use bitbucket for free private repos? You don't have the possibility of corrupting your repo with an unsynced commit from a differennt machine.

alagu 15y ago
+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 http://stackoverflow.com/a/1961515/45582 [2] http://shikii.net/blog/ignoring-funny-ref-error-on-git-dropbox/ http://shikii.net/blog/ignoring-funny-ref-error-on-git-dropb...
- moonlighter 15y ago
  +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.
  - sashametro 15y ago
    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.
kombine 15y ago
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.
- atopuzov 15y ago
  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.
dalore 15y ago
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.
- weaksauce 15y ago
  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?
- maxs 15y ago
  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 http://en.wikipedia.org/wiki/Birthday_problem
  - weaksauce 15y ago
    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 http://book.git-scm.com/1_the_git_object_model.html
- codys 15y ago
  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.

alagu 15y ago

+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 http://stackoverflow.com/a/1961515/45582 [2] http://shikii.net/blog/ignoring-funny-ref-error-on-git-dropbox/ http://shikii.net/blog/ignoring-funny-ref-error-on-git-dropb...

moonlighter 15y ago
+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.
- sashametro 15y ago
  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.

kombine 15y ago

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.

atopuzov 15y ago
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.

dalore 15y ago

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.

weaksauce 15y ago
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?
maxs 15y ago
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 http://en.wikipedia.org/wiki/Birthday_problem
- weaksauce 15y ago
  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 http://book.git-scm.com/1_the_git_object_model.html
codys 15y ago
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.