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

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.

Hi @tappers, I can't get your query flow to work on my machine, would it be possible for you to give me a simple example of a working query ?

Yes. I am also looking for shortcuts even as simple as closing the current task. Currently we need many mouse clicks: 1. Add Action.., 2. Click Change Status, 3. click submit button, totally 3 mouse moves.

I second this:

FWIW, I am using a custom file and mail engine that utilises the AWS SDK and supports instance profile credentials. See P2082 and P2083. You need to install and require the AWS SDK before using these extensions.

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.

unfortunately, this no longer exists, is there a new documentation for it somewhere?

PHP allows and evaluates these constructions:

D18836 probably isn't the right solution, however, it's the only straightforward fix I could come up with. I didn't dig into the details of why it 404s when I fix the code in PhabricatorProjectViewController to avoid the fatal. The patch is probably good enough for Wikimedia, however, I'm not sure if it's good enough for upstream.

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.

Another approach that might make sense would be to highlight the hash and then show a hovercard which lists the commits with that hash. Of course this wouldn't scale too far but it should handle the case where 2 or 3 commits have the same hash.

I tried to work around the immediate fatal by checking the return value of $engine->getDefaultItem() in PhabricatorProjectViewController, however, that resulted in hitting a 404 so it's a bit deeper of an issue. Perhaps the right solution is to prevent users from disabling both of the default items in the project "manage menu" UI?

The apparent lack of support for scheduling in UTC in much more mature calendar software (Google Calendar / Calendar.app) further suggests that this is not an important feature for most users.

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:

Seriously folks, why make this design decision? I have a user with a long history in my Phabricator install that now cannot get into his account and cannot remember what email address he used to create the account. Under a normal system scenario where I'm Admin, I can just go into his account, tell him which address he used, chastise him for forgetting and not keeping notes and that's it.

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.

@epriestley Are there any more concrete plans for this "nonblocking" builds? That is something we would like to utilise for one of our projects. Actually quite important as waiting for builds there is slowing us down quite a bit now.

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.