After arc diff creates a revision in Phabricator it amends the commit to include a link to the revision in the commit message.

In D21685, I've imposed stricter rules for which state transitions are allowed: for example, you can't issue a "pause" command to a build that is already pausing.

I take it these disparate trees have some limitations? Do they always apply to the working directory or something?

I'm still piecing together Git's handling of branches in my mind as I have used Mercurial for so long.

Would the expectation then be that running arc land again would remove the rebased/squashed commits created by --hold, so the result would be as if they hadn't run --hold previously?

There are a bunch of libraries to help with this that I obviously won't be using because I didn't write them...

im a wizard

If I want to go spelunking later to see about improving/adding this behavior is this the right place to do this or is there another place this TODO should go?

If there was a way to run the rebase --abort and discard the result of that it would probably be best.

I think not all versions of Windows + PHP require adjusting php.ini, but some nontrivial subset do -- enough that arc itself emits some flavor of guidance on this:

This is no longer my fight.

For now, this has been working fine as a simple CLI flow.

When using --template I think I was not properly escaping quotes for how they are eventually invoked when launching the process

Ah, yes; DiffusionBlameQuery has a cache.

is there an easy way to log the command that will run from the CommandFuture?

%C ("raw, unescaped comment")

😎

Ah okay, I'll do some other testing. I was also wondering if there would be cases in Phabricator where something is doing something like if (get_class($a) == 'PhabricatorEnv') {... which if so I'm guessing would cause failures.

"Cascading" is updating all local refs which depend on refs that were selected-and-modified by the land operation. So if you have dependent features in several dependent branches named change1 -> change2 -> change3 locally, and arc land change2, we want to (in the general case) rebase your local change3 onto the landed version of change2 so that it no longer has out-of-date ancestors.

This specific issue is probably the relevant one, the other thing linked from there looks like it's just a --debug problem, which this patch should fix.

Requiring very recent Mercurial may also run into issues described here:

reconcileLocalState() is another possible place to put the post-push update logic -- that runs exactly once, and a little later.

A possible approach would be to try to put the "failure" commands into ArcanistMercurialLocalState. I think that would look like snapshotting every bookmark (not just the active one), and then resetting all bookmarks when restoring state. I'm not really sure if this would be better -- your approach seems fairly reasonable to me, and has the advantage of doing all the bookmark management pretty narrowly in one place, and this should be the only place that this work needs to happen. Offhand, I think I favor the approach you've taken here.

One other case where "Phabricator" appears is in HTTP and Email headers, e.g. X-Phabricator-XYZ. For a separate project wanting to update these I think a slow migration approach is needed, to allow recipients currently expecting the existing fields. I'm guessing there isn't a reasonable change here for the upstream.

Ah, I didn't realize annotate --template arrived so recently. Phacility production has Mercurial 2.8.2 and I can't easily fix that at the moment, so I don't want to bring version bump all the way to 4.6 upstream today. I'm okay with the jump to 2.4 upstream, and also okay with leaving annotate --debug without filtering upstream (since no one has complained in all this time, and not addressing it doesn't make things worse). So I'd propose:

I should probably just set up a blog or something since I don't expect to bring any microcontroller components upstream, but until then:

(DiffusionLowLevelMercurialPathsQuery has an example of using PhutilBinaryAnalyzer to do a Mercurial capability test.)

On navigating the version stuff, I think the pathway would be:

Keep the protocol/domain on one line and the path on another (in this case path is <80 chars)?

Proof-of-concept only for class_alias():

This is a bit out there, but: PHP once had something called classkit and later runkit, which perhaps exists as runkit7 now, that let you dynamically rename classes at runtime. In theory, you could use this as a compatibility layer to support mass renaming of classes: if code asks for PhabricatorXYZ, look for GenericXYZ (or XYZ, or consult a mapping), then make a runtime copy of the class. This narrow capability may be in PHP's core as class_alias(), now.

Create Platform::getProjectRepo() to return "phabricator", or instead detect the repository name.

The results in T13649 -- where none of these results actually print a character that anyone would consider to be a "smart quote" (?) -- aren't exactly inspiring, but I think this is a step forward at least.

I think the global flag is reasonable.

Oops -- I assumed you were already in Blessed Committers. I added you, you should be able to either arc land or "Land Revision" now (if arc diff uploaded to staging properly). See that project description for some details, or yell if you're still having issues.

Oh, just for completeness -- you can trigger the first message by visiting this URI while logged out (e.g., in an incognito window):

• Allow "owners.search" API to read this setting.

I added you to Blessed Committers, so you should be able to land this yourself. See that project description for guidance, or let me know if you run into issues.

(That was really me.)

This is approximately working now, although the "button" is currently this mess:

See T13656 for followup.

Instances technically have a formal "Deleted" status -- but it isn't really used by anything, nothing ever puts them into that status, and there are no instances in that status. For consistency with existing CLI workflows, I'm going to rename this to "Destroyed".

A related issue is that I think nothing currently destroys S3 data. For most instances this isn't significant, but it isn't helping anything. This should likely be part of the database destruction step, although it can probably interact with the S3 bucket directly.