"Use the API" seemed to work OK. Of those instances, only bastion005 is at all unusual.

I want to make sure the infrastructure is headed in the right direction overall before fixing unit tests

begins to provide for this

D19706 begins to provide for this. I'm just going to roll the rest of it into T13098 since most further changes are likely to be entangled.

The lint unit tests are significantly entangled with general lint infrastructure, so I'm now looking at making arc lint run again: I want to make sure the infrastructure is headed in the right direction overall before fixing unit tests, so we don't end up with a narrowly-scoped fix to the lint tests that needs to be rewritten once arc lint comes online. In particular, linters currently have their hands very deep in repository / working copy information. Although I think it is plausible that a linter may want access to this information (for example, we have a unit test method which reads configuration to render a link to the Phabricator install, which doesn't seem strictly bad), I think linters and unit tests should not require this information and we should not need to build an entire working copy to run a linter.

This has effectively expanded in scope into T13098.

This doesn't seem actionable and is likely mooted by T13098.

This is effectively fixed by T13098, which modularizes test output.

Now that arc unit runs, I'm going to try to make the test suite pass so that tests are a useful tool in moving forward. We currently have 162 test failures.

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.