(I'm about to cut the release, so just pulling this...)

Another quality Security update from Phabricator! 🐕

Mostly from the HN thread, other possible providers we haven't tried yet include Mandrill, Postmark, and Sparkpost.

T12677 documents previous general issues with mail providers. Mailgun gets the worst of it there, but just because we've been with them for a while without anything too awful happening.

The install in PHI271 reported this as fixed after upgrading.

Two other ideas for reducing magic here:

This pain may be mostly derived from prior to D18842 and git performance improvements. At that time, delay until the prompt was ~4s, plus the overhead of noticing, pressing ^C, remembering command-line arguments to git clean, and the startup overhead of the arc diff startup again:

$ time arc diff --preview < /dev/null
You have untracked files in this working copy.

(I don't really like the magic ignore either, but I worry that no level of safeguards can ever make "delete all your files" actually safe, and moving all your files to .git/arc/trash-can is even dumber than .git/arc/ignore.)

Or put another way, if you arc diff, hit this, ^C, go fix it, and arc diff again, shouldn't that cost you like 2 seconds vs using this ! option? Or is the stat cost huge and it's more like 30 seconds?

A possible reduction in the magic is to give the ignore file the same lifetime that the temporary commit message gets -- basically, if you ^C out of arc diff your choice is remembered, but if arc diff runs to completion it is forgotten.

I'm really, really hesitant to have arc destroy user data, even if they sign a pledge in blood that that's what they intend (e.g., see T8879 for a case of user regret over a bright red, clearly labeled, nondestructive prompt). bin/remove destroy prints out a full-paged gigantic red ASCII art skull and only administrators can run it, and we still see occasional confusion about it.

The code currently shows:

Untracked changes in working copy:
(To ignore this change, add it to ".git/info/exclude".)
  foo

...so remembering the path to edit isn't hard, as it's right there. The problem is more the immediacy -- it can be several minutes until one is back at a prompt to be able to run the hypothetical arc ignore, at which point we have the same problem we have now.

After D18857, I'm not aware of any remaining, reproducible issues with Mercurial. If you're still encountering protocol issues after upgrading through D18857, let me know how to reproduce the problem you're seeing.

T13036 is a more focused rebrand of this issue, since this has a lot of philosophy and not a lot of actionable reproduction steps. The three line fix in D18857 may have resolved these issues.

Mercurial's protocol negotiation presumably considers the size of the change being transmitted in selecting the protocol format

For the (2) case I've sort of imagined possibly building an arc ignore ..., since copying paths into .git/info/exclude does seem like it's the major barrier. The UI could then say "use arc ignore <path> or arc ignore --everything --forever" or whatever, and maybe that'd be a lower-enough barrier to get users over it. I'm a little bit sympathetic to this case since I don't remember .git/info/exclude myself offhand.

👍

I think pressing ! accidentally is difficult -- it was chosen that way. We could bulletproof further via making it require typing I swear under penalty of perjury that I absolve arcanist from any and all fault when these files are removed at the prompt, but that might be a bit much.

I think D18857 fixes the pipe issues. Here's the problem:

What's the specific kind of file driving this?

There's still a call to it in DiffusionServeController.php which I think does have an effect (although I haven't confirmed this).

Here's some evidence [that filtering bundle2] doesn't work:
we attempt to filter the protocol and tell the client that we don't support bundle2

Actually, this is less crazy than I thought.

This appears to date back to the introduction of the feature in D5738, where I suggested we use ancestors() without a legitimate reason (or maybe very old Mercurial had weird behavior).

We can't reproduce this, and can't fix issues we can't reproduce.

This is possibly connected to T9548 but we don't know how to reproduce this and can't fix issues we can't reproduce.

I'm going to hold this for PHI270 since that might change this into a "status" field with several values like "Enabled", "Disabled", and "Temporarily Disabled For A Minute".