Add --upstream option to gclient to scrape git checkouts back to upstream state.

Add --upstream option to gclient to scrape git checkouts back to upstream state.

This will be used on the bots when calling apply_patch, which commits to git
repos.

R=dpranke@chromium.org,szager@chromium.org
BUG=

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=209040

[Dirk Pranke, 2013-06-27 19:57:51]

Most of my comments can be summarized as "why remote repo instead of upstream
branch" ? Why isn't reset-to-upstream-branch good enough?

https://chromiumcodereview.appspot.com/18006002/diff/1/gclient_scm.py
File gclient_scm.py (right):

https://chromiumcodereview.appspot.com/18006002/diff/1/gclient_scm.py#newcode268
gclient_scm.py:268: default_rev = "refs/remotes/origin/master"
It seems like refs/heads/master can't be the right default rev in any case. I
also don't like using hard-coded branch names, period. Perhaps this should be
'{u}' (in both cases) ? 

Lastly, I would flip the order of the two branches so that you don't also need a
'not', if you end up w/ two branches.

https://chromiumcodereview.appspot.com/18006002/diff/1/gclient_scm.py#newcode283
gclient_scm.py:283: revision = 'refs/remotes/origin/master'
This doesn't seem right. In what situation do we say -r HEAD explicitly ? 

I would be more inclined to either leave -r HEAD alone or err out saying that -r
and --nuclear are incompatible, but maybe neither of those are acceptable?

https://chromiumcodereview.appspot.com/18006002/diff/1/gclient_scm.py#newcode439
gclient_scm.py:439: target = 'refs/remotes/origin/master' if options.nuclear
else 'HEAD'
Same sorts of comments as above, plus it's not clear to me that this shouldn't
just be a part of the UpstreamBranch() logic above on 401-409.

[iannucci, 2013-06-27 22:56:51]

Yup you're totally right. I'm not sure if '{u}' will work in gclient crazy-land,
but I've taken an upstream-branch-centric approach in v2. PTAL.

https://chromiumcodereview.appspot.com/18006002/diff/1/gclient_scm.py
File gclient_scm.py (right):

https://chromiumcodereview.appspot.com/18006002/diff/1/gclient_scm.py#newcode283
gclient_scm.py:283: revision = 'refs/remotes/origin/master'
On 2013/06/27 19:57:52, Dirk Pranke wrote:
> This doesn't seem right. In what situation do we say -r HEAD explicitly ? 
> 
> I would be more inclined to either leave -r HEAD alone or err out saying that
-r
> and --nuclear are incompatible, but maybe neither of those are acceptable?

If we have deps e.g. third_party/WebKit@HEAD

[Dirk Pranke, 2013-06-28 00:16:57]

LGTM, except that now that things are nice and simple, I'd probably rename this
to --upstream and "Make repo state match the upstream branch."). Do that and
update the change description and we're good.

[iannucci, 2013-06-28 00:28:41]

On 2013/06/28 00:16:57, Dirk Pranke wrote:
> LGTM, except that now that things are nice and simple, I'd probably rename
this
> to --upstream and "Make repo state match the upstream branch."). Do that and
> update the change description and we're good.

Ok!

[commit-bot: I haz the power, 2013-06-28 00:33:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/iannucci@chromium.org/18006002/8001

[commit-bot: I haz the power, 2013-06-28 00:35:27]

Change committed as 209040

[M-A Ruel, 2013-07-08 19:13:02]

On 2013/06/28 00:35:27, I haz the power (commit-bot) wrote:
> Change committed as 209040

Why not
--upstream == --reset --force ?

[iannucci, 2013-07-08 20:22:25]

On 2013/07/08 19:13:02, Marc-Antoine Ruel wrote:
> On 2013/06/28 00:35:27, I haz the power (commit-bot) wrote:
> > Change committed as 209040
> 
> Why not
> --upstream == --reset --force ?

Because --reset resets to HEAD, which is wrong.