Is there a practical use case motivating this? The cases I can come up with are:

We could really push two refs: phabricator/diff/12345 and phabricator/base/12345. To phabricator/base/12345, we push the first parent of the last thing that pops out of git log HEAD --not --remotes -- (that is, the first ancestor of the diff which is also present in any remote)?

From D13041, it looks like the first time git does a push to a totally separate staging area it pushes a lot of extra data, probably because none of the heads in the remote are ancestors of the head being pushed, so it can't detect that their ancestries are 99.9% identical.

See T7604.

make the fullscreen mode z-index some smaller value

I configured this for our repos; only hiccup so far is that there's no way to disable "Commit Hook" Herald rules right now so the first pushes (which pushed the entire repo history) took a little while. Normal "arc diff" staging pushes only take about a second.

A clean-ish but very non-general fix would be to load PhabricatorStartup explicitly before using it in code which might be hit on a non-web pathway. It looks like PhabricatorAccessControlTestCase.php already does this.

T8259 should partially fix this.

This was sorta fixed by D12922.

Ah OK, so it seems to only affect my mobile device (Chrome on Nexus 5).

I guess that's reasonable.

Maybe put "../arcanist/bin" as the first component of your PATH? That should work from arcanist/ or libphutil/.

That would mean always running ./bin/arc (from rARC) or ../arcanist/bin/arc (from rPHU), which I thought would be manageable but it turns out to be annoying.

Can you just... not run different copies of arc in other different copies of arc? Crazy workaround, I know.

So, anyone have any clue what we use "primary owner" for?

Installs which relied on "Arcanist Project" Herald rules don't necessarily have a perfect way forward; "Owners"-based rules are one of the alternatives I suggest in the upgrading guide in the description of that task.

What does this have to do with T7604?

D13024 fixes this for Owners.

I can't immediately reproduce this, but Owners is in generally bad shape. I think I can justify spending at least some time unearthing it because of vaguely related work in T7604, though, so let's see how far I get.

Yep, that's right. My plan for the upstream to move forward in the short term (until we build virtual refs) is:

In the general case, this is working as intended. Specifically, it's intentional that we accept linebreaks in the middle of a "Fixes X, Y" statement, because linebreaks aren't always added explicitly by users.

It looks like we can push to some secret place:

I have this working, but pushing to tags in the same repo is pretty leaky. The docs say this of git fetch:

spooky!

See T8089 / T8097. We are moving away from the "postponed linters" mechanism, specifically.