In D19697 I claimed my next plans were "Windows, signal handling, and prompts", but I think arc unit needs to work again before I can convincingly do the Windows stuff. So it looks like signal handling and prompts first.

In my case (using GMail) it appears to thread properly as well however apparently some clients (KMail) rely on these headers more heavily than others.

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.

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.

@epriestley: I can help with testing and validating on elasticsearch, if that helps at all.

Actually, we can go one step further than D19686, I think.

We have a general initialization order issue where a later config file may define a load/--library setting that includes a typed Setting/Config object for a setting value in an earlier file. So I think this needs to happen in several phases:

T11934 is not exactly adjacent here, but I suspect it feeds into some other incidental goals and may provide a workaround for some things which get removed.

I'm looking toward making arc alias work in the general case again, but the big thing this is blocked by is reliance on config.

As a note, we make quite a bit of use of --arcrc-file currently to "handle" multiple people working as root on dev VMs, but we can probably migrate that over to --conduit-token anyway (although we're a way off hitting this, because as much as I want drafts, other people consider T4678: Support changelist-based SVN workflows in Arcanist and Differential critical and we're on a fork because of that.)

See T13098 and T13203.