From location1, if you just want to be able to make your working copy look like origin/<branchname>, you don't have to create a new branch. You can checkout on a tracking branch. You just can't do all your normal work there (i.e., when you want to commit, you'd need to checkout a branch to commit on). If you want to create local branches that track all the remote branches, the command you're currently using (minus the --track option) is what you need.
As for deleting a branch, the simplest way is to not push branches that you're not going to keep. I understand what your context is, so you'll likely be stuck with maintaining branches in your central repository.
There's not a dramatic simplification I can see in your workflow, but here's where Git's strong-suit really kicks in: it's very, very scriptable. It would be nearly trivial to write simple bash scripts to do most of this in one command (you might even be able to get there with aliases).
Regarding the push command, it currently does not allow both the --all and --tags options to be used together (very strange).
Regarding not pushing temporary branches, this seems contrary to one of the reasons I started using git: it makes branches cheap and easy to throw away when you are done with them.
I can understand the way git works regarding each developer using only the branches they are interested in, but I can't seem scale this philosophy down to a single developer. I want all my working copies to be the same. I want new branches to propagate. I want branch deletions to propagate.
I've thought about scripting some of this, but for some pieces I am not sure how to proceed. Consider branch deletion. The problem here is that I can delete the branch from the main repository, but that doesn't force deletion for each of the clients. Instead, I would need to write a custom "git pull" style command that I run in a working directory before I start my work. Should this command delete all remote branches so that actual deletions are propagated, and then "git pull" restores the remote branches which still exist?
[edit: I've discovered that "git remote prune" will delete remote tracking branches that are no longer in the repo]
Don't other git users have this issue? Presumably there are others who work from more than one location and want a consistent view from each, yet I can't seem to google for any help on these issues.
Yeah, I realized post-facto that --all and --tags doesn't work. Alternatively, you can list your tags with things to push, like
git push origin master my-tag ...
That might also work with --all. If it does, you could get away with:
git push --all origin my-tag
As for the rest...I'm not sure what your best way forward is. One way might be simply to don't delete branches. They'll clutter the list of branches, but so what? Just ignore them if you don't use them.
The 'git remote prune' way is probably best. Run that, and then check for local branches that aren't tracking a remote. That's scriptable.
I don't think there's a simple and elegant answer here, because what you're doing basically turns Git into subversion. That's pretty much unavoidable when one is doing what you're doing.
You could be more "distributed" if you only worked on specific features or modules (or whatever) at specific locations. Then you could just merge when necessary instead of always having to keep your branches in sync :-)
As for deleting a branch, the simplest way is to not push branches that you're not going to keep. I understand what your context is, so you'll likely be stuck with maintaining branches in your central repository.
There's not a dramatic simplification I can see in your workflow, but here's where Git's strong-suit really kicks in: it's very, very scriptable. It would be nearly trivial to write simple bash scripts to do most of this in one command (you might even be able to get there with aliases).