The stalled transactions on this host published after I deployed the update.

(After picking up D21697, the approach works properly in my environment where I originally ran into this, but there are a couple of rebase calls still present in ArcanistMercurialLandEngine that don't use the new API yet.)

I just use TextMate, which is a fairly lightweight editor. I have it minimally configured to disable a couple of default behaviors and add a couple aliases, and I have a crude "jump-to-definition" script set up that tries to open whatever file defines the class/function under the cursor and succeeds about 95% of the time.

...the one with --onto-remote default not appearing in the trace output...

Thanks! Couple of minor inlines but I didn't catch anything substantial.

This happens when a recipient list includes an Owners package which has been destroyed. Specifically, we'll exit this section of PhabricatorMetaMTAMemberQuery with out the PHID in $package_map, and then fail to return it:

There a bit of fancier indent/formatting stuff in some of the newer code (e.g., in ArcanistRefView->newLines()) but it hasn't really generalized into something you could easily apply here yet. I think this is fine for now and we could revisit it to make it fancier later on if the newest display stuff gets generalized a bit.

Maybe the output could be two separate lines:

That all looks good to me.

We could conceivably prevent that error by making GitLocalState keep a trivial stack (just a stack of true) and return its current depth (0, 1, 2, ...), then throw if the passed $ref was not the current stack depth.

Since modern Arcanist usage with Mercurial has required the arc-ls-markers for a while now and nobody else has reported issues, I think it's fine to not try to address these issues for older versions.

...perhaps we should consider a way to do this automatically or at least less-manually.

This makes me think that in this second scenario where running arc diff initially includes multiple commits that the revision should be updated to include the commit hashes for each, and then might result in having better detect this scenario if it's searching for revisions with associated commit hashes.

• Cryptographically Random Orbit Sander

Sounds good. I spent 15 seconds on trying to write hg arc-amend, and this does something and does appear to produce an amended commit that looks ballpark-correct (and can amend non-heads), but emits some warnings and I have no clue if it functions across Mercurial versions:

My only guess is you've delved into the Mercurial source base (I've poked around a little)

I don't think LocalState should z̵̰̲͚͖̊͗́̓̓a̷̛̱̯̠͐̿̅̅͛̓͗ĺ̵̨̻̠͓̼̗̥̥̻̲̳̎͜ͅg̴̛͙͗̀̄̈́̃̂̓̄͝o̶̥̘̻͙̬͇͚̥̪͌̔̃͛̆̀̂̚ͅ your terminal!

This is probably not a great path to walk down, but there are secret flags that disable the "cannot amend changeset with children" check:

Another possible approach might be to copy the amend extension to create hg arc-amend which just lets you amend anything, assuming the "head only" rule is a safety guard rail rather than a fundamental issue with Mercurial (which it seems like it should be).

Ohhhhh, sorry, I didn't connect the dots and understand that you're only sometimes running the amend (since you can't amend for non-heads).

This ("Queued at") looks suspicious:

I'm not catching on to what you're referring to. Are you saying there are other changes which will have already stashed unsaved state away before calling amendCommit()?