mirror git repos: rsync vs. --mirror

I'm trying to see about the state of automated mirroring git repositories between different systems, eg. a private backend and a public frontend, and ran into a catch between two possible options, each with a downside. If there are other means besides these, I'm all ears for them.

rsync:
------
How:
- Simply rsync the git repository, atomically, and use --delete-after.
Benefits:
- Guaranteed to match between master/slaves.
Caveats:
- Need to know that the master repo is in a good state.
- If a repo is repacked, there is a lot more traffic in the next sync.

git clone --mirror && git fetch:
--------------------------------
How:
- Setup with: "git clone --mirror URL"
- Cronjob with: "git fetch"
Benefits:
- Extremely fast
- Light on traffic
Caveats:
- Branches and tags deleted in master persist in slaves :-(
- Seperate gc/repack needed on slaves.

The traffic vs. deleted branches/tags is the main tradeoff here, esp. as repos get larger.

Can git-fetch perhaps be made to delete the branches/tags?