I think we probably solve this incidentally by doing T3855, T9537, making --onto mean in the remote, and defaulting it to the tracked branch (although I think it already does?). The only problem with this is that land-example wont get updated but from T9537 maybe you're completely fine with that?

I guess that won't quite do what you want since you're legitimately tracking a local branch which tracks a different remote branch in this case. But maybe you're partially doing this only because T9537 doesn't work?

In the specific case of the local branch existing and tracking a remote branch of a different name, I think we can use that other name by default. However, it potentially puts us in a situation where we receive an identical request asking for the other behavior and have no choice but to add --ignore-source-tracking, --ignore-destination-tracking, --onto-remote, etc.

At some point, I think we hit diminishing returns where we cover 95% or 98% of workflows and getting to 99% requires adding twice as many flags. Somewhere around there our time is probably better spent on tasks like T5055 so it's more practical for you to distribute a replacement arc workflow to accommodate your unusual requirements.

Anyway, pretty much same story here as T9537 -- I want to sort out T3855 better first, then we can tackle refinements here.

It seems perfectly reasonably to tackle the specialty-workflow problem via T5055, rather than blowing up the number of Arcanist flags. And, as you suggest, I think T9537 will largely eliminate my desire for this, since it will allow me to name my local feature branches whatever I want, and I'll only have to type the long remote branch name at feature branch creation time.

So, in short, everything you said makes total sense. Thanks!

(In this case I think your behavior is the more natural one and I'd probably want to tell the hypothetical future users wanting the other behavior to go build a custom version of "land" via T5055 with one million flags, and they may not really exist, I just want to have some sort of contingency plan in mind before making the change.)

(Cool—that seems very reasonable.)

Oh, sorry, D14356 doesn't actually fix this.

D14357 fixes this. The new behavior is to recursively resolve upstreams until we:

• reach a local branch with a remote upstream (use the remote upstream and remote branch);
• reach a local branch with no upstream (ignore all the tracking/upstream information -- possibly we should use the last branch we reached?);
• reach a local branch we have previously reached (print a waring about the cycle, ignore all tracking/upstream information).