Good to know. Thanks!

We're running 216f6be11ece53cb1daafc8fff636dbdb0d7ef3d, not the SHA given above.

Enabling that form seems to have done the trick -- thanks! Since it got renamed at some point from "Create form," its existence was almost certainly confusing to some previous admin, which is what got us into this.

I do now see that, but I'm unclear how to use its form to configure the form to configure the form to configure the form from.

In D17507#209885, @epriestley wrote:

Oh -- it avoids foreach (null as ...) for commits with no "Auditors" field, which emits a warning since foreach (...) wants an array.

The table in the description references a getConduitFieldKey method – which I can't find reference to ever existing in the source. Was that supposed to be getFieldKeyForConduit?

Yup, will try to get this upstreamed.

Non-backtracking forms of the two repetition characters.

Fix typo in comment

Fixed by D17188.

Rebase and re-run unit tests.

I think that's unrelated to this change, and purely based on the yacc version in the environment. Mind if I split that out into a separate diff?

metamta.email-body-limit is unset.

Aha -- the diff as posted for review was mostly-reasonably sized. The diff as committed was the huge one:

mysql> select differential_diff.id as diff_id, creationMethod, SUM(addLines), SUM(delLines)
    ->   from differential_changeset
    ->   join differential_diff on differential_changeset.diffID = differential_diff.id
    ->  where differential_diff.revisionID = 253041
    ->  group by differential_diff.id;
+---------+----------------+---------------+---------------+
| diff_id | creationMethod | SUM(addLines) | SUM(delLines) |
+---------+----------------+---------------+---------------+
|  837437 | arc            |         11845 |          8567 |
|  837558 | commit         |       1752986 |        396108 |
+---------+----------------+---------------+---------------+

bin/worker execute --id 35362582 did not work because the task was archived. Instead I ran ./bin/phd stop; ./bin/worker retry --id 35362582; ./bin/phd debug PhabricatorTaskmasterDaemon. The key seems to be the production of the .patch file itself, not the number of files. Somehow these users managed to cram a >100M patchfile into Differential:

It will likely be easiest to replicate again after upgrading to Week 52 stable this Friday, since I can't use precise same diff, and don't know the precise set of replication criteria yet.

Hm; we weren't running HEAD when we reported T11748. We have an upgrade planned to latest-stable in a week or so -- will that be sufficient to re-test with? Or is there a repository that we can apply a 4,800-file diff to on Phacility?

This is a necessary, but not sufficient[1], step to be able to make the server better able to reason about stacked diffs. We use this as part of our CI integration, but it is currently used in the arc patch workflow as part of the message when the base commit is unavailable; it is used to suggest This diff is against commit D12345 rather than against commit 8badf00d.

Somehow another change snuck in, though I don't see it locally?

Do normalization on checking in isRelevantMessage, not during
storage in paths.

That seems reasonable. I'll push an updated diff later today, which tries both forms of slashes in isRelemvantMessage() if running on Windows.

This is still logged as an EXCEPTION. Is DELETE FROM phabricator_repository.edge WHERE type = 39 a reasonable step to take, to prevent administrators unfamiliar with the non-fatal-ness of this from being worried?

This can cause a storm of commit mail when upgrading. If there are old tags which weren't imported at the time, when Phabricator is upgraded to a version containing D16129 it can fire off thousands of commit emails, flooding inboxes and making some folks grumpy at their Phabricator administrators.

Address review comments

After further testing, this is only relevant now because git < 2.9 did not do rename detection by default; it was enabled in 2.9.

Use new libphutil functions.

Using SSH master connections has two advantages:

1. Connections are indeed faster. In a minimal case (SSH'ing to an adjacent machine on the same network), it reduces the time for a no-op SSH connection from 0.14s to 0.01s. The utility of this grows as one needs to tunnel SSH connections in order to access a machine; for instance, SSH'ing to our Phabricator instance requires bouncing through a bastion host; using SSH master connections reduces the time to connect from ~0.7s to 0.01s. This is notable since arc may produce mulitiple git commands which attempt to fetch from upstream.
2. Authentication information is preserved. If the connection does two-factor authentication, for instance, the user may be supplied with an authentication prompt when the master is set up. Re-using the master preserves this authenticated session, and reduces the amount of re-authorization that the user must do.

Ack -- sorry for having forgot that fixup.

The problem was even though the upstream remote of the branch I was working on was in this arcanist, the remote named origin still pointed to our internal fork. Temporarily swapping the names of the upstreams around made it work.

Nope, no staging area:

$ arc diff HEAD~
Linting...
 LINT OKAY  No lint problems.
Running unit tests...
   PASS   16ms★  ArcanistLibraryTestCase::testLibraryMap
   PASS    9ms★  ArcanistLibraryTestCase::testEverythingImplemented
   PASS   36ms★  ArcanistLibraryTestCase::testMethodVisibility
 UNIT OKAY  No unit test failures.
 SKIP STAGING  Unable to determine repository for this change.
Updated an existing Differential revision:
        Revision URI: https://secure.phabricator.com/D14420

Actual no-op diff

No-op diff