The real Pandora's box this opens is that now that arc is exposed to whatever issues arise with the raw Python/Mercurial API, there's a much weaker argument against not writing more extensions.

I put the extension in phabricator/ earlier by accident, but that was just me goofing my local paths. The extension is purely client side: hg can do ls-remote just fine (it's just "do hg pull, but stop half way through"), there's just no UI command for it.

Would the use of an extension make additional setup necessary for observed repositories vs. hosted repositories, or are observed repositories out of scope for these set of changes?

I am considering reviving the command server since I don't remember it having any critical failures, but offhand:

I'm going to try writing a Mercurial extension instead.

I believe this is roughly the form we end up with, which is completely ridiculous and extremely difficult to test or have any confidence in:

As a tool developer, this kind of thing is infuriating:

This is also made more complicated because Mercurial branches and bookmarks are all in a single shared namespace to some degree. I'm not sure what happens if you try to fetch a bookmark that conflicts with a local branch name (presumably: it renames it as "divergent"?) or try to fetch a branch which conflicts with a local bookmark name (presumably: fails in a way that's hard to detect?).

When the user specifies arc land --onto marker, I'd like to identify whether marker is a bookmark or branch.

See T13545, T13547, T13548, for the next round.

This approximately exists now via T11968.

I'm not 100% sure I got this, but all of these seem to work now: