I got an amazing array of answers to my question, and I thought I would share with you all, the answer I was looking for, care of Nathan Corvino, among others.
The initial error, about updating the current branch of a working copy is denied because it will make the index and and work tree inconsistent, and will require a git reset --hard to fix it, is there to prevent you from forcing changes over someone else’s local work. Allowing this would be roughly the same as if subversion allowed one user to force another’s working copy to update every time they committed. This would have the possibility of wiping out local changes, and generally fostering ill will amongst developers everywhere.
My mysterious error also suggested a setting could be used to override this safe-guard, (the recieve.denyCurrentBranch setting) and indeed it can. However, it still doesn’t quite do what I expected. Before I tell you about what happened, lets briefly explain what a git repository contains. When you run git init, by default you get a normal repository, which contains a working copy, and a .git folder, which has all the information about versions, branches, tags, etcetera. There’s a flag on the command --bare that will create a repository that is intended to be pushed to and pulled from, but never worked directly on. It is only the .git directory. I briefly tried the “regular repository with denyCurrentBranch turned off” setup, and after I pushed the first set of changes, adding my site files, I checked the server version of the repository I had just pushed to, expecting to see them shiny and new. What I saw instead, was still and empty directory. when I ran a git status on that directory, it told me it was ready to delete all the files I had just added. This is where I got really baffled, and backed away rapidly. What was actually happening, was that I had pushed the changes into the repository, but that hadn’t updated the working copy. Instead, it made it look like the working copy was a set of changes that I had created from our new “Tip of Tree”, and so obviously we must want to delete all those files that aren’t in my working copy.
There is a way to make the setup I wanted, and I was most of the way there. The rest of the way would have involved setting up a post-recieve hook to run git reset --hard on the repository after the push. This would have kept the working copy win sync with the rest of the repository, allowing the working copy to update, whenever an external push happened. I’m going to leave my setup the way it is, though. It’s easy to understand the way it is now, in case I need help with something I can explain what I’ve done. If I ever need to move my site elsewhere, I could put my intermediate directory in bit-bucket or github without too much change from the current configuration.
Credit to Nathan Corvino, Tim Ekl, Alan Storm, Jim Correia, Jeff Nadeau, and Liz Marley for various explanations that got me to a place of understanding! Thank you all, and anyone I may have forgotten to mention!