Here are some of the bigger ideas around arc unit:

This has existed for some time and will be the only option after T13098.

I'm going to roll this forward into T13098, which is essentially a superset of all the ideas here except arc build (a new step which can: generate code, generate artifacts shared between lint/unit, and prepare a working copy to be able to execute unit tests). That will probably happen, but likely after T13098 stabilizes.

In theory, arc unit is next on the docket so we can start getting test coverage, then Windows support. However, I suspect arc unit may unfurl into a lot of substeps.

For prompting, the major things I want to do are:

I've marked D19705 as fixing this. Some stuff still doesn't work, notably:

In a directory with a file foo bar:

Some general notes on this after putting far more time than feels valuable into it:

How did anyone get computers to do anything before 2005?

I'm going to merge this into T11934 since I now expect to provide a more general version of arc edit <object> and make all comment areas support these commands.

Can't reproduce:

This feature has been removed in experimental and wilds, and I don't currently expect to restore it.

In T13098, I expect to remove both of these warnings because:

We haven't seen friction here from other installs in the last few years, and I think (?) this encourages a questionable practice (assuming unreviewed changes in the working copy should be amended) in the general case.

As requested, this is the same as T1508, "when I run arc diff, each commit in the range should be preserved and visible in the web UI".

I don't plan to pursue this.

I think this has failed to collect any compelling use cases in several years and don't plan to pursue it.

See also T4953. I don't really understand this use case and suspect Harbormaster now solves it (when revisions are updated, run a build which deploys the changes to a sandbox). It sounds like the use case is really "would arc patch do anything?", not "would arc diff --update do anything?".

This is intended and has legitimate use cases.

This will be fully modularized in T13098 if it isn't already. I don't expect us to upstream a JUnit formatter, per T10038.

I don't plan to pursue this, as requested.

This is many years old, hasn't seen further reports, and no longer has usable reproduction instructions.

Piece by piece, this was effectively untangled. Differential largely moved forward; Arcanist has a path forward in T13098 (although it's ultimately a "major version" sort of change), and Diffusion stuff has settled into relatively actionable plans in, e.g., T13075.

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.