A sometimes-suitable replacement would be some bin/request mechanism which simulates a web request in process. There are some limits to how authentic this can be, but for some substantial subset of hangs it may still be useful.

PHI1776 is another report of this behavior.

A related issue is that it is difficult to identify the set of "published" hashes in the general case. We would like arc branches to show all unpublished history, but stop at published history.

The major issue I'm trying to deal with now is that if you have a tree like this:

P2143 has some graph reachability code that I don't actually need yet, but may by the time I get here.

The current ls-remote script as written does not actually work; I think it only returns branches in the remote that:

The actual extension is a 100-line Python script...
The real Pandora's box this opens...

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:

After D12336: