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.

Since observed repositories version differently today, this strategy won't work -- but I can't come up with any valid reason to ever put a repository into a "write maintenance" mode anyway. I do imagine making observed repositories "replay" fetches into the push log (as though they were pushes) in the future, but that still won't make "write maintenance" on an observed repository meaningful, so it seems fine to just prevent putting non-hosted repositories into this mode.

A minor issue on the way to this is that calling synchronizeWorkingCopyBeforeWrite() with an omnipotent viewer will write to the WorkingCopyVersion table with a null userPHID, which shows as "Unknown Object" in the UI.

A useful maintenance operation for staging area repositories is to remove out-of-date staging refs: old diffs which have already landed. This is of some particular importance for large installs, since Git has a significant per-ref overhead for many operations until protocol v2: by the time a repository has ~50K refs, interacting with it in basically any way has become slow and cumbersome.

D21668 should improve this behavior, although it's not an ideal or complete fix.

...this would need some kind of smarter scope guard...

I also can't get O_NONBLOCK to survive process exit on macOS. This is possibly because macOS is now zsh, and this RedHat bug suggests that zsh clears O_NONBLOCK:

arc may leave stdout/stderr nonblocking.

secure002 and secure004 are likely easy to take out of service, since they're pure replicas.

See PHI2090 for another report of this. Chrome hasn't changed behavior since the last update, so I'm more inclined to look at workarounds.

A point against AllowEncodedSlashes Off which I hadn't connected the dots on is that "security researchers" from HackerOne will report URLs like this as "content injection vulnerabilities" for all time:

It may be doing it that way to avoid the possibility for missed timer overflows?

I'm starting with an absolute bottom-of-the-line 3018, I've "upgraded" it with a plotter collet I made out of a pool noodle and a piece of cable gland so I'm less likely to hurt myself for now:

The digestWithNamedKey() issue above generally impacts anything using immutable caches, so it can affect CSRF too.

• This is far afield from any application I have today, but it seems plausible to operate a small-scale DIY plastic foundry (Ref) that converts plastic waste into blanks for machining or injecting into machined molds.
  • The cost to just buy premade plastic blanks doesn't seem particularly high (roughly comparable to plywood?) although I know nothing about plastic qualities.
  • Unsurprisingly, it seems like the market for recycled plastic material doesn't have a lot of DIY buyers (unit sizes are often: 1,500 pounds; per metric ton; per 40,000 pound truckload; "*Only Quantities of 10k lbs Plus").
• There are a handful of people doing extremely high-precision DIY EDM machining (Ref).

Yes. I closed down registration on this install (secure.phabricator.com) several years ago because the overwhelming majority of users who registered accounts here didn't read or follow the rules. Access to secure.phabricator.com is now invite-only.

One call to for-each-ref comes from resolving a list of commit hashes, to test if they still exist. This is accomplished with DiffusionLowLevelResolveRefsQuery, which calls git for-each-ref first and falls back to git cat-file --batch-check.

Has this repository changed?

This is now in stable; presuming it works until evidence to the contrary emerges.

D21656 fixes variables_order.