Version?

Not exactly related, but these cancel buttons used to be grey and are now blue:

Some other general thoughts:

Sorry, I guess I'm being unclear: I don't believe that (1) is a reasonable starting point.

I think maybe we're talking about a couple different things? These are both relatively easy:

have a flagged filter automatically everywhere

Maybe also, in general, we could define an "explore by tags" view, that works something like this:

Constructively, some adjacent changes which are maybe worth considering instead:

The requests I've seen seem like users want this done automatically/by default, not that they want better tools to do it themselves.

On a purely personal/aesthetic level, the box-drawing character block is total garbage and master ASCII artisans would never use it in serious work. A true connoisseur of the craft should accept nothing more than single-byte ASCII range in their collection.

See some related discussion in T12822. In particular:

me too but not everyone is on our level

• T2495: Improve whitespace expansion of tab literals is somewhat adjacent here.
• T11632: Display invisible characters on erroneous user input is a little related: if we generate canonical lists of "invisible" characters in UTF8, they should probably be shared by all three of: the code that detects when input in forms is invalid because of invisibles; the future UTF8-aware invisible mode; and the UTF8 text linting mode described in T11150.

Per above, these are already detected by the Text linter:

See also T4124 for another Solaris issue.

The move completed without errors.

Instances are moving now.

Deploying, then picking this up again.

I suspect some of those features have no actual use case outside very marginal nonsense like T12799, but they're "things computers should be able to do".

I want to get clear of T12798 first, but there are some other features I'd like to add to our search anyway, including:

I'm going to call this "resolved" since I migrated instances in T12817 successfully. There's followup work, but T12798 is probably a better point of consolidation for future work now than this task is.

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.

Maybe just include name, value, closed and special?

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.

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".

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.

Maybe this was the workflow?

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.)

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 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.

(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#226522, @bjshively wrote:

The pagination view for very large source trees/folders (in our case located at ourdomain.com/diffusion/name/browse/master/averylargefolder/) is confusing. Specifically, the pagination buttons are placed below related Open Revisions. This can often be confusing or misleading, as it is not immediately obvious that you're not seeing the full set of files.

It might be clearer if these buttons were immediately below the content being paginated (i.e. sandwiched between the averylargefolder list view and the Open Revisions.)

Existing sources of permanent failure are worth at least a cursory review before we ship this since they're pretty easy to grep for, but I don't anticipate any issues.

See also T7339 and T5554. But the approach we are generally taking there is "wherever possible, use a method where locale configuration is not relevant", which is consistent with using -f -.

This works properly on my local machine (OSX) so it's some kind of Ubuntu UTF8 CLI thing.

This is now available in HEAD. See M1476 for a mock. The actual feature doesn't quite look like that yet since the buttons use generic styles, but should soon (see also T12688).

On GitHub, all remote URIs are read/write, but in Phabricator some may be read-only.

Some purely technical stuff: