In T13053#235208, @epriestley wrote:

Hrrrm...

Do you mean "follow up in PHI55"?

We've also had a request for this (disabling the in-application popups) at #dropbox, as a per-user preference.

#dropbox has also encountered this since upgrading from MySQL 5.5 to MySQL 5.7, and thus an InnoDB FTS backend.

Beautiful. Sorry for not finding that.

Sorry, just pulling that out. 4d2c7e4d3d5d61e34b7e2af3df0e901d89d29433

Noted, OK. We'll proceed by adding our own local ./bin/storage endpoint for it.

Would you be adverse to accepting a patch that does this?

Aha! That works wonderfully. I think this is INVALID, then.

Thanks for the fixes! Most folks are on Chrome at Dropbox, so Safari being subject to the Heisenprod Uncertainty Principle doesn't worry me much.

T11997/T12032 look related, but not the same behavior.

Forgot to specify browser: this is Chrome 58.0.3029.110 (64-bit) on OS X and Linux. Also replicates on Safari 10.1.1 (12603.2.4).

Based on two points of anecdata so far, things indeed seem snappier with D17959.

Understood -- thanks for the clarification. One isn't always aware of how special-case one is. :)

Sorry, that seemed to be in response to "are you working on this?" A user has since provided a patch for the feature, which is the sort of thing which in the past you folks have generally been nice enough to review.

Phacility folks, do you have thoughts about the patch provided by @lyngvi above? Would be it be easier to review if submitted as a Diff?

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.

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?

Fixed by D17188.

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 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.

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.

Sent D14420.

The URL to push to is constant. The ref to push to, however, would depend on what one was merging into -- hence what I mean by needing to be computed. Implementing this would also require replacing all of git-receive-pack on the server side; pushing into refs named by the server allows the server to not worry about magically hiding that overlap. As is, the server can manage the refs as normal refs, which works effectively.

How does removing the API call simplify matters? One still needs to have code to construct the name of the ref to push to (even if that's just a string concatenation). Doing that computation on a remote machine, rather than locally, makes little difference.

Hm, interesting. I see a few problems with that technique, though:

D14365, applied locally, does fix both issues.

Yes, an explicit --ff makes it complete:

Aha -- I have merge.ff = off in my ~/.gitconfig, which causes:

This appears to have broken a couple workflows that I would assume to be common. Using c844669, I now see the following:

At Dropbox, the data shows that in our major git repository, 2-3 users hit the "You can not land a branch onto itself" message per day — so this isn't an uncommon occurrence. Is there something we can do to help prioritize this task, such that arc land DWIM in more cases?

This is also a notable backward-incompatible change to projects which define their own lint engines; all places which generate their own ArcanistLintExceptions by hand need to be checked to ensure that they call setName. This upgrading note likely bears documenting somewhere.