Were the (technical) employees happy about it?

I.e. was it just a crazy requirement handed down, or did they not know better?

I just can't imagine it even for solo development, nevermind collaborative work! "Agh. We must have had a merge conflict, damn, the core part of my work is gone... Let me see if I have a recent copy... Oop, no, I don't, because I've run out of disk space from all these clone backups."

FWIW, I use git inside Dropbox for my personal solo projects. I don't want to have to use commits and git's remote syncing mechanisms to share in-progress code between my desktop at home and my laptop. I want to be able to pick up exactly where I was on the other machine, including my git staging area and local unstaged changes. It works perfectly for this.

I do occasionally get Dropbox-level merge conflicts for tmp editor/IDE files, but I can't recall getting any for source files.

So, neat trick: "git clone" your local Dropbox copy somewhere, and you get the benefits of "commit" and "push", but it's local; and then your remote is synced via Dropbox :)

> neat trick: ... and you get the benefits of "commit" and "push"

GP seems to be deliberately avoiding commands relating to remote management, such as push.

I use a similar setup. I use spideroak hive since its 'zero knowledge', I don't however sync any binary or IDE directories. This allows me to have the source files and git repos synced, but still keep somewhat independent set ups.

just so you know, git on dropbox is not a great idea in a team. solo it should be fine but you are probably better off using bitbucket for free.

All projects were single developer. It was a burn and churn environment. Contractors from all over the world, share a folder from the root, they work in it, when they completed it, the folder was unshared and they were paid.

It worked OK for that purpose. And I still have dropbox mainly for that reason. My source code is always local. Everything goes into TFS, but the local is backed up to dropbox.