arc upgrade: Upgrade everything? This feels sort of bad/dangerous, maybe? But maybe fine? We could prompt?

I guess you're right. We've never really questioned the behaviour of these GUI tools. We assumed that because they do this automatically and provide no way to disable it "they'll probably know what they're doing".

Part of the tension here is that any package-related command potentially has two targets: arc itself, or the current working directory (Phabricator, some third-party app you're developing, etc).

None of that really does anything yet, but the next steps (signing, installing) need to have major components in arc, so I'm going to consolidate this into T8115 / T5055 and other related arc work.

(We could detect this case and fail with an error, but the root issue here seems to be that tracking is being set on a remote branch which the local branch really does not track.)

Generally, I'm very hesitant to use "will the push change anything" as a signal, because I think this is unintuitive and will create confusing false negatives. Specifically, if you do this:

Have you asked Sourcetree or Git Tower to change their behavior instead? They can compute ahead/behind without setting tracking, and it seems like setting tracking is not really correct here (the local branches do not really "track" temporary remote CI branches in the traditional sense).

I'm not sure actually. Most of us use GUI tools like Sourcetree or Git Tower, which automatically set up tracking when a branch is pushed. I guess they do this to be able to show the "Commits behind / ahead" badges on branches.

Why does the local branch track the remote branch? Do you push using --set-upstream? If so, why?

I see the same behavior noted by @lianghu in T9042#129510.

Excellent! Thanks for this so very detailed answer. I will try the way of the phid.lookup to work this issue around in the while.

Looks like that'll work nicely!

Thanks for the report, and for the good reproduction instructions. D16313 should raise a better exception.

There isn't enough information provided for us to reproduce this issue. See Contributing Bug Reports.

T5088 is a possible use case (report if the current revision needs an update), although I feel like it's a bit flimsy.

T10895 is a reasonable followup for --revision / --do-what-I-mean-instead-of-what-I-say.

I think we missed the window on this one.

The arc help land documentation was improved by T9657.

After T10431, aliases are also read from system configuration.

After the introduction of PhutilHTTPEngineExtension (T10227) we have a more viable pathway to bring support for this upstream, but I'd still like to see more interest in it before thinking about upstream support. It looks like only 1-2 installs would use it, today (not sure if both of you represent the same install or not).

See T6072 / T11356 for discussion.