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.

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

Ah, thanks for the pointers!

In D21484#272642, @epriestley wrote:

Minor nitpicks inlines, I'll just tweak them locally as I land this.

(Since this wasn't submitted with arc, the Git "Author" information has been lost and the commit will be incorrectly attributed to me as an author. If you submit further patches, you can use arc to retain authorship information if you'd like.)

Minor nitpicks inlines, I'll just tweak them locally as I land this.

Internally, see also PHI1785.

PHI1816 would also like dimensional coverage: coverage by language; coverage by team/owner. This is perhaps worth considering in how coverage is aggregated.

This appears stable.

PHI1776 is another report of this behavior.

• In previews, suggestions aren't highlighted properly (likely just missing CSS).

(there's usually no value in reviewing individual file-level changes in a "create a new branch X" commit)

Completely agree that there's no value in reviewing those individually. But to be clear, my point in making this ticket was mostly that you can't discern from the browser that this was a "create a new branch" commit. Right now it just renders the whole file tree saying showing 3000 files individually copied instead of a simpler/single line saying the whole directory was copied.

Since many of these options probably don't have "right answers", I'm trying this reasonable-seeming variation on some repositories which seem like they'll benefit from a repack:

• j, etc., can incorrectly select blocks inside a diff inside a suggestion.

I made a change to drop unchanged context from suggestion views, but I don't particularly like it. It changed this:

• Inline comments with suggestions don't "know" that they're empty when the suggestion is the same as the context text.
  • Create an inline. Suggest edit. Don't change anything. Save. You get a blank inline with no suggestion and no content, when this inline would normally delete itself.

The inline comment context menu does not apply the correct cursor ("pointer").

I still have a lot of inline style attributes to clean up and then I'm sure there will be a long tail of weird edge cases, but this is getting pretty close:

• This isn't necessarily terribly useful in practice, but a UI hint about whether or not we've actually saved a draft would make debugging slightly easier.

Remaining work here is:

• The inline comment context menu does not apply the correct cursor ("pointer").

These particular issues blame to D21027, which began extracting null in all cases where a field has no value for a given commit. This is not entirely faithful, as it can not distinguish between "field absent" and "field present, but with an empty value". At least for author, these are distinct states that can be independently constructed using git hash-object:

From PHI1739, --allow-empty-message supports constructing these commits more easily (via a normal git commit rather than git hash-object).

Second issue:

First issue:

Alas, you can't actually push the perfect commit:

• The line-triggered reticle should be updated to use the hover-reticle cell style.