3 ms·
You'll probably end up corrupting the shared bare repo. This approach is only suitable for a small team (two in my case) where people can just shout over their
by DTrejo 16y ago
You'll probably end up corrupting the shared bare repo. This approach is only suitable for a small team (two in my case) where people can just shout over their cubicle walls: "Hey! Nobody push! I'm pushing now!". – Ates Goral Sep 13 '10 at 20:04
- xpaulbettsx 16y agoThat's generally not as likely as you'd think - since the names of the files are hashes of their content, the worst that can happen is you'll get dummy files. Bob's 8331a5b is just as good as Sam's 8331a5b. You could conflict refs (like where 'master' points to), but that window is generally pretty small.
- DTrejo 16y agoThat's good to hear, especially since I have a number of my personal repos in my dropbox.
- skybrian 16y agoWhat about git repack?
- bdonlan 16y agogit repack won't delete any files until it finishes creating a new packfile. You might end up with a window in which the deletions are synced but not the upload of the new pack - this means git operations from other hosts may error out, but there'll be no permanent damage once the sync finishes. Additionally, git won't delete orphaned objects in automatic GCs until a certain time period passes - so no problem with concurrent commits. And if all else fails you can always undelete every file under .git/objects through dropbox :)
- roel_v 16y agoYeah, people defending this 'solution' made me go 8( , too. Felt like I was right back in 1997, doing 'version control' with carefully numbered directories because Sourcesafe 'is overkill'.