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

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

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.

T13023 provides an example of a synthetic "git-like" diff generated by some tool (dpkg-source?) which appears (?) to pretend to generate Git diffs (diff --git in the text).

I'll merge this into T12664, but realistically it's exceptionally unlikely that we'll add the ability to parse these diffs given one example and no idea how to generate them in the general case, and apparently only one install encounters these diffs, and they aren't generated with a legitimate VCS tool.

The fix for T13031 may have made this worse by default, since we now extract all pushed changesets and hold them in memory by default, even if no Herald content-based rules which use them actually exist. This may create too much memory pressure if you push a very large number of commits.

The chatbot was removed completely in D17756.

PHP allows and evaluates these constructions:

With T13001, the commit page itself now gives you disambiguation options if the commits are in the same repository. This is a narrower case than ambiguous commits across multiple repositories, but related if we did pursue something like hovercards or a multi-repository disambiguation page.

T13028 is a followup but I think everything else here is resolved.

T10604 and T4369 do not impact LFS (broadly, they apply only to POST requests, and LFS uses PUT to upload data).

Adjacently, some other parts of the UI currently use the word "enormous" (see https://discourse.phabricator-community.org/t/herald-enormous-check/822). They should be rewritten to use different language (like "Very Large"). We should use the term "Enormous" to mean only "too large to process completely", while the other UI uses it to mean "large enough to partially collapse for viewer convenience".

Also, while it's on my mind, all repositories should probably have this rule today:

See T7789 and D18827. Block Git LFS in some repositories:

See PHI242. SR Latch:

D18831 should upgrade this from "horrible fatal" to "reasonable-but-not-ideal normal page". This could still be improved (providing the user more information and taking them into the submodule redirect workflow) but it's normally difficult to end up here without trying.

We have an outstanding support issue (PHI204) about timeouts with large files.

No.

Per above, pushes to staging areas did not push LFS in the past. We should figure out what the state of the world is now and try to resolve it in the upstream, and document anything we can't work around or resolve.

@Grimeh, above, reports that this doesn't work over HTTP. I believe it does, but we should verify this.

As @avivey suggests, the remaining cache can be cleared with:

Anecdotally, Disqus uses Akismet and the hit rate isn't great (I've observed both a high false positive rate, and a high false negative rate).