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
That'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.
git 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 :)
Yeah, 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'.
