repo should either enable git push or grow a repo push subcommand

There are certain cases in chrome-os where we bypass review, and do direct 
uploads.  Things like builders signing off on a change, thus us up-rev'ing a 
manifest/ebuild to expose the actual change to our stable users.

For this, we've basically hardcoded the server to push to; this however sucks 
since we have the necessary info in the manifest already (and hardcoding breaks 
down if two review servers are in use).

As such, attached is a patch injecting a pushurl if a review url is specified 
for the remote.

The flaw with this is that if the gerrit server's ssh_info has changed since 
the user sync'd, the pushurl will still point to the old location; there really 
isn't any way around that if we're exposing `git push`.

If that's acceptable, ok, patch is attached.  If not, I can hack up a repo 
push; I'm wary to do this however since repo push isn't exactly equivalent to 
`repo upload`; uploading several feature branches in parallel is sensical.  
Trying to push multiple feature branches at the same time however is a bit 
dodgy- the user has to ensure they will merge nicely (which if not, means one 
is already live).

Frankly I don't like that; could do repo push branch [project]+ instead (thus 
preclude the issue via limiting the UI to single branch pushing).

Since most folk are using uploading, I went the git config route instead.  If 
that doesn't suffice let me know and I'll hack out the subcommand approach.

Original issue reported on code.google.com by ferri...@chromium.org on 22 Dec 2011 at 7:39

amersons / git-repo

repo should either enable git push or grow a repo push subcommand #100