What behavior do you expect?

What would you like us to do differently?

This is working as intended.

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

Why are you running arc install-certificate with a manually entered URL?

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).

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

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.