(dis)advantages of staging dev->production using 'drush rsync' vs 'git'? I set up a Drupal site under git control for development work.

It's parented in a master, bare GIT repo, and as changes are made in my various project-work git clones, and pushed back to the master, a post-update hook immediately pushes the changes to a single live Staging website (http://staging.loc.). Nothing special, works as expected.

I've also drush-aliased the site "@STAGING". On occassion, I want to promote my changes from the Staging site to a production server.

Two relatively straightforward methods come to mind:

(1) At a point in time when the Staging site appears stable, create the Production site as a git checkout from the master repo,

(2) use drush rsync + drush sql-sync from the staging site to the production site.

Both can be made to work.  Other than the fact that (2) seems more Drupal-centric/aware by nature -- drush is, after all, a Drupal-specific set of tools -- what are the relative merits of the two approaches?

Is there any particular reason I should consider (1) over (2)? 

In either case "Everything" is under at least one instance of revision control ...
I have used both techniques.  Both can be used to guarantee that the same files that you test on @stage end up on @live.  The advantage of rsync is that you do not end up with extra files (e.g. ".git" and associated) on your production server.  I tend to rsync to a vps, and use git on a box I own (e.g. intranet sites).