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.

• Test for "svn" before running an SVN test to fix the local test failure, since this new machine doesn't have "svn" installed yet.

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.