+1 for this command. We have use a web-based UI for landing so our branches stick around locally. To fix this I'm currently using:

arc branches | grep ' Closed ' | sed 's/[^ ]* //' | sed 's/ .*//' | grep -v master | grep -v '^[0-9a-f.]*$' | xargs git br -D

Recently smtp-relay.gmail.com stopped accepting email from our Phabricator instance because it turns out Phabricator was sending HELO localhost.localdomain instead of HELO smtp-relay.gmail.com when doing the SMTP connection.

I'm not completely thrilled about maintaining PHP builtin webserver support...

In T13575#254280, @epriestley wrote:

I added M1, etc., to the ignored list in D21507.

I think this is now resolved. I'm not completely thrilled about maintaining PHP builtin webserver support because I think use is very limited, but since I'm currently using it I expect to support it at least until I summon the nerve to deal with Homebrew.

Guess I should probably add M1 to the remarkup blocklist now.

I switched to an M1 Mac Mini on Big Sur, which has motivated me somewhat to try to get this working since I suspect doing another install through Homebrew on M1 silicon will be more adventure than I have stomach for.

So I don't forget:

With the four revisions I've just added, arc lint works with PHP 8 when run inside the arcanist repo, and arc unit --everything has no regressions compared with PHP 7.4 (both do have a few failures but they're the same and relate to pyflakes/jshint/hg, and look environment-specific so nothing to do with PHP 8).

In D21496, declaring a method private final (which is redundant, as a private method may never be overridden) causes an issue in PHP8.

Just want to add a note that with git lfs managed files, arc patch won't work unless one fetch the ref tag and then the lfs blobs from the staging server first. See https://discourse.phabricator-community.org/t/arc-patch-fails-with-git-lfs-files/2447/3

As of macOS X 11 (Big Sur), php on the CLI emits:

That seems reasonable. I also ran into a couple of other suggestions elsewhere:

Off the wall suggestion: how about a trigger that sets the subtype:

The profiling in D20566 seems satisfactory, and has been useful in resolving or understanding a few performance-related issues.

• There is no way to pull custom field values with *.search. See above.
  • There is no way to edit non-custom field values with *.edit. The underlying transactions haven't been modularized yet; they should be, then EditEngine should get appropriate EditField definitions.
  • There's no way to identify which custom fields can be edited. This overlaps with T13248, but is also a Conduit API Console UI problem. The web UI should have some way to inspect parameter variations per object subtype for available subtypes.
    • As a workaround, you can try to edit an invalid field. The error message will identify valid fields.
  • There's no way to create steps with *.edit because you can't specify a step type. See T13449 for a general variation of the "type is required to initialize objects" problem.

HarbormasterBuildStepCoreCustomField emits no fields if a BuildStep has no attached Implementation object. This dates from D15352 and is conceptually reasonable ("don't crash if a build step exists but the implementation no longer does") but should probably be represented differently (e.g., an explicit "InvalidImplementation").

This appears fixed by D21484 (and @20after4 confirmed the fix on rPc0414732 -- thanks!) so I'm going to mark it as resolved.

See https://discourse.phabricator-community.org/t/strpos-throwing-in-phabricatorauthpasswordengine/4335, and D21477.

I know it's an old thread, but I am encountering what is, as far as I can tell, exactly the same issue. I'm on the latest version of trunk (~Oct 26) with php 5.5.9 on Linux 3.13.0. I also observed the issue on the May 30 version.

I think I've got a small tidbit to add on a specific use-case with Jenkins. I had been using pipeline builds which are working nicely but I just tried to setup a multi-branch pipeline build and this requires the branch name in the Jenkins URL of the HTTP request triggering the build. I suspect in this case the proper thing to do would be to trigger and build twice. I guess that's more of an on-branch-change sort of situation than on-commit and using those triggers in Herald (they look to be present, I haven't used them) and having that information passed on to Harbormaster as mentioned could fill the need.

Same issue here.

This synthetic script demonstrates the conceptual problem with FutureIterator:

I've marked D21461 as resolving this, since the new errors surface the particulars:

• D21457 fixes approximately 20 additional errors identified by the linter in phabricator/.

I just created a poll where I accidentally hit enter while editing options, so I was left with an incomplete poll which I wasn't allowed to complete, so I had to close it. Would you consider adding a feature that allows us to edit poll options as long as there are no votes cast yet?

• D21454 fixes the specific issue in HTTPSFuture.