Please don't forget to update Phabricator before filing bug reports.

The disabled/suspended instances finished up with no apparent issues, so I expect to move the live instances tomorrow.

A verrrry minor thing is that because we always transfer a repository backup (even if it's empty), a migration always generates a repository directory on the far end. We could maaaybe have restore remove the directory if it's empty after the restore finishes to tidy this up just a touch.

With only those fields:

{
  "data": [
    {
      "name": "Open",
      "value": "open",
      "special": "default",
      "closed": false
    },
    {
      "name": "Resolved",
      "value": "resolved",
      "special": "closed",
      "closed": true
    },
    {
      "name": "Wontfix",
      "value": "wontfix",
      "closed": true
    },
    {
      "name": "Invalid",
      "value": "invalid",
      "closed": true
    },
    {
      "name": "Duplicate",
      "value": "duplicate",
      "special": "duplicate",
      "closed": true
    },
    {
      "name": "Spite",
      "value": "spite",
      "closed": true
    }
  ]
}

Maybe just include name, value, closed and special?

Similar example for new maniphest.status.search. I'm happy to drop any of these fields if you think we won't need them (prefixes and suffixes leap to mind).

I'm moving all the disabled/suspended instances now.

With those changes, bin/instances move completed successfully.

As a sort of aside, --global --instance X is really slow right now (about 10s), and will only get slower in the future: it loads every instance page by page over Conduit, then does the remaining filtering by name locally. But it gets the right result, so this is reasonable enough for the moment. I may try to tune this before moving a lot of instances.

I hit two more minor issues:

bin/host restore failed with this error:

I read and wrote the repository and verified that the data really ended up on db012 and repo025.

I launched yellow-underneathie.phacility.com with forced services dbx012 and repox025. My goal here is to check for any code I missed which makes the assumption that dbX = repoX. I believe we don't have any of this code, but if we do, this instance should point out whatever problems we have that still need to be cleaned up.

• Swap stuff finished up.
• I merged master to stable for services/ to pick up bin/services sync --src ... --dst ....
• I merged master to stable for instances/ to pick up bin/instances move ... and related changes.
• core/ just runs master so nothing needed to merge.
• I upgraded repo025, then repo012, then admin001. None of these seemed to hit any issues.

While that's running, I closed dbx012 and repox012 to new allocations. The shard status panel correctly reflects repox025 with no paired DB service and the 012 shard as closed:

• I launched repo025.phacility.net, like other hosts in the tier.
• I added repo025.phacility.net to DNS in Route 53 (172.30.0.115).
• I added a device record (repo025.phacility.net) to Almanac on admin.phacility.com.
• I added a service record (repox025.phacility.net) to Almanac on admin.phacility.com, and bound it to the device.
• I added a device record for the backup volume, rback025.phacility.net.

I think the next steps are:

I cleaned up all that stuff and it doesn't look like I broke the world.

I think this means we don't need to migrate every host: the problem with swapping block001 over to be NAT'd was probably that the NAT gateway itself couldn't reach the public internet. When we changed the 0.0.0.0/0 rule to nat-..., that blocked the NAT gateway itself from getting out.

• I launched a new NAT gateway into the public subnet (block001); nat-0d470fc54d846a993.
• I reconfigured the private subnet route table to point at the new gateway instead of the old one.
• I can now reach the public internet from the host on the private subnet:

I think the problem is that the NAT gateway is currently in the private001 subnet, but needs to be in the public subnet (the NAT gateway itself must have a route to the public internet).

• I stopped the host, and got kicked off as expected.
• I started the host.
• Problem: This failed to magically fix anything, and I still can't connect to the public internet.

• I built a new route table, following the main route table.
• I replaced the target for the 0.0.0.0/0 rule with nat-... instead of igw-....
• Under "Endpoints", I added the new route table to the S3 endpoint so the private subnet can access S3.
  • (This wasn't immediately reflected in the "Routes" UI, but it's not important for now so I'm going to assume it's a propagation issue until I need it.)
  • (It showed up about a minute later.)
• I changed private001.phacility.net to use the new route table, with nat-... instead of igw-....
• I can still connect to the test host from the bastion.
• Problem: I still can't connect to the public internet from the test host.

• We launched a new private subnet (private001.phacility.net) yesterday.
• I launched a new instance (nat-test001.phacility.net) into this subnet, with no public IP.
• I can connect to the instance from the bastion host (bastion005), which is good.
• Problem: I can not connect to the public internet from the test host.

The behavior of arc land is complex. You can look at the source for the details, or run arc land --trace to see which commands it executes.

By headless strategy you mean the squash and merge one ?

Per @chad's link, PholioMockEditor->buildMailBody() does some improper stuff where it explicitly sets rendering targets and adds raw sections to the mail body.

Prior to October 2015, this flag only had an effect under git. This is why it says "Supports: git".

Gah I searched "mockup email" not Pholio..

Arc supports auto-deleting the remote branch as well as the local one

The version of arcanist used is the one packaged in debian.

See T12814.

I got an email about the last update but the contents look like some of the content is not HTMLized properly

A common reason for this is that users treat git push like "Save Changes", and the remote has thousands of epriestley-tmp-fix-T123-tmp-bakcup sorts of branches.

T12776#225510

999.99999.9% sure we have this tracked "somewhere"

good stuff, thanks!

I resorted to hg log -r "descendants('XYZ123')"

Maybe this was the workflow?

Oh jump to the history via pagination and scroll to it? I don't know if that's technically possible. It's interesting though.

Hmm the history view on this install is significantly different than the one on mine~

The button. That says Browse. 💃

I just came across this today, though I can't recall a time in recent history of it coming up previously. I was looking at a commit in history and wanted to browse through history at that point - if there was a way to jump to the commit history at the point from a commit, would've helped. In this scenario I knew a commit was made shortly after the one I was tracing and trying to locate - that doesn't happen often though.

Great! I was hoping this could be done with some kind of a plugin/extension. I'll look into it and let you know when I have a working solution.

To set expectations, this is an exceedingly low priority for the upstream and these tasks basically only move forward when an existing customer requests integrations.

(T12812 wants custom headers, but the only use case appears to be better covered by T12813.)

Alrighty, I'll take a look at it. 💯

Mock above rebased on master and apparently working:

Let me see if I can dig up my hack-branch above and hand you a skeleton for it.

Yeah, this is relatively simple if it's on a separate page, and can be built in 20 minutes if there's no sorting or "Hide Done".

To step back slightly, one problem we know users have, which is motivating at least some of this request, is "90 spelling corrections". T8909 has a specific example of that, and T8909#224085 alludes to a flavor of this ("90 style corrections") elsewhere. I don't think this is a problem that users "should" have, but I suspect it's responsible for between, like, 50% and 85% of this request (maybe I'm way off, but I'd bet dollars to donuts that it's more than 2%), since it's the case where managing inlines is most overwhelming. And human reviewers are somehow often unable to resist making 90 inlines about style/spelling corrections, even when everyone is worse off for it.

I do think this is something I would have used in the past when faced with ensuring I've addressed all feedback for multiple designers. So in some part, I feel I understand the core problem users are looking for. I don't think we can fix abuses like the 90 comments on spelling errors, so that's not something I feel I need to consider in this design. I just want to make sure I haven't missed anything as an author, or that as a reviewer, all my comments have been satisfactorily addressed. There could be something to explore in that second directive, but we haven't seen a lot of issues in that area, so I'm not really concerned if this is the best solution for that. Wanting a view of only inline comments and the ability to reply isn't something I want, as I feel Differential already does that.

I suspect that isn't what very many users want (I'd guess like ~10%, not ~98%?) -- or, at least, doesn't really solve whatever problems they're running into. For example, I think the "90 spelling corrections" diff in T8909 wouldn't benefit much from this (it doesn't help you go through 90 spelling corrections or 90 lint style fixes), and it's the opposite of the request in T5654, which sounds very similar to this to me. But maybe T5654 is really just "our users like GitHub, so make it look similar to GitHub so it's more familiar", I'm not really sure.

Alrighty, took at pass at this I think isn't too much work, and is probably 98% of what people want. Specifically tried to look at the following scenarios:

My solution to this problem was to compile version 3.4.2 of mercurial and install with a different PREFIX, and only use it for pushing to phabricator. That way I can use the latest version of mercurial for everything else.

@jcox ???

(We also likely have a similar problem for hg that D18105 won't fix, and can't use the same strategy there since hg grep has no -f flag or equivalent.)

Note that D18104 is not retroactive, so existing feed stories aren't expected to change after upgrading. New feed stories published after picking up the fix should show "alice committed <commit>" as the title again, though.

It looks like the current behavior rose out of D16268 / T11309, although it was something of a side effect of those changes.

In T12804#226525, @epriestley wrote: