I now strongly believe this is some kind of terminal environment problem. This script has different behavior in production and on my laptop:

No luck, I don't even see any bugs in Differential locally with that change (the en-dash decodes and renders properly). So this might be in the realm of T7339.

Same result.

Same results for spaces.

To try to reproduce this, I did this:

One possible approach for this is:

I'm going to roll this forward into T13057.

T13049 is a followup about generalizing exporters.

Rename the field to "Reviewer (Legacy)", or move it to a "Legacy" category -- maybe improves things, but really just punts this.

I believe this is supported now (and for some time) in the general case in terms of Phabricator infrastructure. Actually getting it to work requires a very smart highlighter, and the upstream XHPAST highlighter is the only one in existence. But other tasks, like T3130, are better homes for parser/AST improvements to particular languages.

As some general commentary on this:

@20after4, heads up that we're going to start exposing pull logs, which contain remote addresses in the upstream. The visibility policy will likely be similar to push logs.

I believe this has been supported since D11543, in 2015. Specifically, log.ssh.format supports %k, and it appears to work as expected.

From https://bugzilla.mindrot.org/show_bug.cgi?id=2496, this is apparently fixed in the OpenSSH upstream (https://github.com/openssh/openssh-portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2). Since this is a bug in OpenSSH, an upstream fix is available, and the impact is fairly narrow, I don't plan to work around it in Phabricator.

I'm going to close this since it was mostly answered and the remaining questions (about custom extension development) are outside the scope of modern support. See T13039 for a followup about numeric fields in Herald.

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.

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

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?

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

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.

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.

This can be "fixed" like this:

Phabricator messes up tab spacing in patches. It should be very easy to replace tabs with spaces and require the use of only monospace fonts.

I don't see this increasing storage usage - just shifting it. Right now because Phacility doesn't support LFS, all those large files are going straight into Git, which not only ends up on an EBS SSD, but also has to be cloned every single time which increases bandwidth usage. At least with LFS those costs are going to be from S3 (which I believe is cheaper than EBS SSD per GB), and bandwidth would be down as new clones no longer need to pull every version of a large file in the Git history.

I think the current state of things is:

PHI181 has an entangling concern (T11372).

In T5463#172345, @florianb wrote:

I ran into the same issue, it turned out, that the permissions for /phabricator, /libphutil and /phabricator as well as for the preceding parent-directory had to be 755.

Until i figured this out i tried running all directories with less permissions (750) - which did result in a

AuthorizedKeysCommand /usr/share/phabricator-ssh-hook.sh returned status 126

I really don't know which user is here trying to invoke whichever script or command (since all defined users [git, phd, www-data] are nicely coupled in their phacility-group), but since i wasn't able to track that down i think that's a good compromise. And it should be safer than letting root invoke the AuthorizedKeysCommand.

Tangentially related here and to T12611, the traffic volume from the ongoing "attack" in T13003 filled /tmp on admin.phacility.com. I pruned some old logs for now, but the mitigations in T12611 (e.g., separate log volumes) would resolve this properly.

PHI109 captured a slightly more illuminating error. D18692 has some discussion.

@epriestley I've pinged you via pm about prioritization.

Sorry to leave this hanging, but the issue was with our server configuration. We did not have the correct sudo rights confgured

This is now in stable, and deployed here and to the Phacility production cluster.

For record-keeping, this was asked again in https://discourse.phabricator-community.org/t/469

In T9548#229910, @indygreg wrote:

https://www.mercurial-scm.org/repo/hg/file/default/contrib/phabricator.py is a Mercurial extension that allows you to send a series of changesets to Phabricator by calling Conduit APIs directly. The extension is currently tailored for the use cases of the Mercurial project itself, isn't distributed with Mercurial, and may require Mercurial 4.3. And it obviously bypasses Phabricator's built-in Mercurial server. But if you are willing to live with the caveats, you may find it a suitable workaround.

I deployed this to secure without issue, so it looks like LOCK TABLES ... is promising as a general tool for migrations.

This is now deployed on this server, we'll see how it holds up. It won't promote to stable until next week, and I'd discourage anyone from picking it up right away.

In Mercurial, can a branch have some open heads and some closed heads?