Oh, using it for deployment, so you're moving directly from one computer to another right after making a change and then using those files? I could see how that causes problems sometimes. I think the use case of "here is my checkout, I edit it on multiple computers, I don't use it as anything else" is a lot more reliable.
I think you're on to something here. It might be both safe and convenient to use git with Dropbox iff you create a bare git repo that is not in a Dropbox folder, and then specify a separate worktree that is in a Dropbox folder. That might give you the best of both worlds, but I haven't tested the idea.
There aren't any fundamental issues with putting the git repo in Dropbox. Under normal circumstances, to cause a conflict you'd have to do something that writes to the git folder, then switch computers, pull up the same checkout, and do something else that writes to the git folder, all within less than half a minute.
And even then it's just something like having disagreement about an index file. Easy to resolve.
The fundamental issue is that Dropbox changes are non-atomic w.r.t. what git considers "atoms." See my other comment in this thread. You're right that there's usually not a problem with a single contributor, but if you ever have two or more contributors sharing a Dropbox-contained repo it will be bad news.
Sure, don't share. But there's a good use case for putting a single-user checkout into Dropbox, and that's because it adds convenience and gives you continuous backups.
Though outside of garbage collecting, git doesn't have many files that actually get changed. Mainly the ref pointers which are easy to resolve and the logs which aren't very important.
