Nice catches! I managed to catch those later but not before the code actually hit them and died. 🦂

libphutil/ currently includes a ~2.5MB "xhpast.exe". I took this opportunity to remove it.

In order for threading to work in email clients, the Message-ID header needs to be set on the initial email, with following emails having In-Reply-To / References set to that same Message-ID.

I can't reproduce this: mail threads properly in my client.

This rolled into the "nuke libphutil forever" change, but I'm not currently planning to land it to libphutil prior to that because the things it addresses are all very niche and there's some possibility it does goofy things and breaks the world or something.

• More-tested version which removes ZSH support since it doesn't work.

Also, damn, I've used libphutil for so many things - ExecFuture and HTTPSFuture are just by far the best thing out there for async work.

press_f_to_pay_respects.txt

I'd imagine replacing master and stable in libphutil/ with a single "TOMBSTONE.txt" file explaining everything, and leaving it there indefinitely. So pulling will keep working, it just won't do anything interesting.

Yeah. rP needs rARC, but rARC is now completely standalone.

The version and/or installation status of xhpast likely differs across nodes on the secure tier, so one file got highlighted by (say) secure001 and got a full XHPAST parse, while the other got highlighted by (say) secure003 and fell back to the Pygments lexer.

In theory, probably. In practice, anything not coming through a support pact is probably going to sit in queue for an eternity nowadays.

Today, arcconfig files are JSON and won't parse if you have comments:

I'm copy-pasting these diffs from the command line with git show | pbcopy, since arc diff doesn't run on any of these branches yet. The git show diff is missing context, versus the git diff -U9999 ... diff that arc generates internally.