[PATCH 0/6] implement @{push} shorthand

The basic idea is that in a triangular workflow, it's useful to be able to refer to both @{upstream} and "the place I would push to" with a shorthand. This idea was discussed over a year ago:

  http://thread.gmane.org/gmane.comp.version-control.git/240144/focus=240198

I've found it useful since then, so I decided to clean it up and submit it. This iteration renames it to "@{push}" (rather than "@{publish}"), which is more descriptive. It's rebased, as there were some changes in the area, and it also fixes some bugs in the original (of course, I may also have _introduced_ bugs, as this is largely a rewrite that has not had a year's worth of exercise).

I also took the opportunity to do some more aggressive refactoring of the remote.c code, as there were some bits there that confused me every time I looked at it. I think the result is easier to follow.

  [1/6]: remote.c: drop default_remote_name variable
  [2/6]: remote.c: drop "remote" pointer from "struct branch"
  [3/6]: remote.c: hoist branch.*.remote lookup out of remote_get_1
  [4/6]: remote.c: provide per-branch pushremote name
  [5/6]: sha1_name: refactor upstream_mark
  [6/6]: sha1_name: implement @{push} shorthand

The one thing I _didn't_ do here is refactor the logic in builtin/push.c so what we could reuse it. There's still a switch statement here on push_default. I don't like that, but I spent an hour or so trying to pull out the push.c logic, and it got rather nasty. There are a lot of global variables that get mutated by one-off functions, and it all needs to happen in the right order. It looked like any serious refactoring there is going to have a risk of regressions in push.

So I punted on that. The simplified logic that is here in sha1_name is not too bad, and I feel like we can unify the two at a later date if we want to. And I'd much rather see bug reports like "@{push} doesn't act like git-push" and deal with that, as opposed to "your series breaks push".

-Peff