Clue: if you're about to give a program you've never used before random commands because you think it should behave how you in your divine, infinite wisdom believe it should; and because the company you work for has a horse in this race and they can do no wrong; and because you can't be bothered to look up what you want to do first--you know, actually just read the links you're going to drop in your mindless, ignorant rant in your blog--just STOP. The right thing to do would be to actually read the documentation you were about to link to before you make yourself look like ********** in public.
From the very same Git Tutorial that you were about to link to in a giant section titled Using git for collaboration
you could, you know, look at the command you think you might want:
Git can also be used in a CVS-like mode, with a central repository that various users push changes to; see git-push(1) and gitcvs-migration(7).
And since you're a very smart person with a history of working with VCS's and a resume a mile long in the FOSS community, you know that that's a giant red flag that you're about to force the tool you're using in a mode that is not distributed.
But, whatever, why do all that when you can feign ignorance and continue to contribute to a months long tirade by Bazaar supporters and Canonical employees and contractors about how terrible, terrible git is and won't someone just think of the poor children? Never-mind that the entire section titled Using git for collaboration
makes it clear that cloning your repo is exactly what you want to do.
Can everyone trying to derail this move just find something better to do with their time. This is getting really, really old. I don't care what DVCS we get but now that we're finally, about to have one, it would be nice if the whining stopped. Or if there is whining, it's researched a little before it's posted.

Comments
I'm a huge git fan (I know more git internals than most) and I still think its UI is terrible for exactly the sorts of reasons the above people state. Those kinds of posts could be taken as calls for action rather than lighting rods for criticism.
I just spend the better part of half an hour reading those git docs and I am still utterly confused.
I am probably dumb, just as Scott apparently is, although I like to tell myself otherwise. Luckily I've been successfully using _every_other_bugging_(d)vcs_ I've encountered, so there is still salvation for my unworthy soul. I am a happy dumb freetard :-)
Still, many of the "Git is impossible to use" guys are probably happily using Emacs or Vim.
How is:
server$ git clone ssh://workstation/path/to/repoor
workstation$ rsync /path/to/repo ssh://server/path/to/remote/repohard? Sure, it's not a --bare clone such as one that might be configured by an administrator that is setting up a shared, central repo that automatically manages GC compaction and arbitrates multi-user conflicts. But that's not what Scott says he wants. He says he just wants a quick point at which to share his work. And either of the two above commands will do that. And they are all over the web. One command, and you're done.
And just to be absolutely clear: after either of these two commands, the remote repo. can be pushed to for binary efficient updates.
It's not a deal breaker (I still choose git over bzr for all my work), but it's a useful command that I wish was part of upstream git instead of something I had to add myself.
And yeah, it is hard. As much as my small brain can understand, I need to login into the server, then do a git clone via ssh back to the server... isn't that a bit backwards? Much easier for me to just send it away to the server, bonus points for not having to worry to setup an ssh connection.
you're using in a mode that is not distributed."
because of course we all work on machines with a public IP all the time. Why does hosting a branch on a server make it less distributed? As all branches are equal any way it doesn't matter that I create a copy for someone to pull from.
James
There is, of course, nothing "less distributed" about having a remote pull-from point that you can push to (after you make the initial clone). The steps that Scott went through were the ones you would use to set up a shared, central repository, not just a public pull-from point.