This at least resolved the obvious badness in the case of PHI1979.

However, the existence of the original code might point at a bug in the "Variable Reused as Iterator" lint check: I would expect it to have prevented the original code in the first place.

As a coarse first pass at this, forcing the commit cache to fail results in a full discovery of the Linux repository in 14 seconds, versus 2m36s with normal cache behavior.

I updated the description, but the relevant workflow is during the "discovery" step, not the "refs" step. The "refs" step uses the RefCursor table and doesn't interact with the commit cache.

It looks like the case in PHI1977 was actually a situation of attempting to trigger an audit by writing a Differential rule, so the Global/Personal stuff may still be worth fixing but has zero known cases of actual confusion in the wild. I'm less sure how the UI could be clarified around the Audit/Differential issue.

After D21518:

These parts seem likely resolved once I convince myself the patches so far actually work:

I have a change to add containerPHID locally, but it ends up having relatively high complexity because several other patches (including 20190909.herald.01.rebuild.php) call PhabricatorRebuildIndexesWorker::rebuildObjectsWithQuery(...), which does not work if executed in sequence prior to a worker queue schema change.

This also relates slightly to T13580, but I believe the two issues are addressable independently.

However, I'd like to have a better understanding of how we're reaching this state, and I'm not satisfied that these repositories are going down the "natural" pathway (of changing ref definitions after the import starts) and suspect there is some more complicated interaction at play here.

I'm hoping to land at least a narrow fix for this today to support an import in PHI1979 tomorrow. However, I'd like to have a better understanding of how we're reaching this state, and I'm not satisfied that these repositories are going down the "natural" pathway (of changing ref definitions after the import starts) and suspect there is some more complicated interaction at play here.

See PHI1977 for a somewhat-similar issue: a user was (probably) looking for an action available only in Global Herald rules, and didn't realize available actions depend on rule scope.

Please use Discourse to report bugs. See https://discourse.phabricator-community.org/t/repository-view-git-command-failed-error/4510/.

It works with Git 2.1.4 (shipped with Debian Wheezy), but not with Git 2.20.1 (shipped with Debian Buster), or Git 2.30.0 (latest version).

My apologies if this is not the right place to post about this, but seems like due to ea9cb0b625fb6922c45aecbfdebacc60788ed92d we now get following error message when visiting diffusion repository page, i.e. URL /diffusion/$REPOID/:

In T3277#254315, @epriestley wrote:

grep -v master | grep -v '^[0-9a-f.]*$'

This part may prove slightly trickier to implement correctly in the general case.

grep -v master | grep -v '^[0-9a-f.]*$'

+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: