Uhhhh, absolutely none of this works because PhabricatorUserEmail does not have a PHID.

Another likely bug is:

Currently, the flow here is that changes queue a daemon task.

Removing an email does not properly disassociate identities. This unambiguously should.

When you set an identity to "Unassigned", we also set the effective PHID to "Unassigned". This isn't strictly incorrect, but probably makes everything more complicated than it needs to be.

• When you set an identity to "Unassigned", we also set the effective PHID to "Unassigned". This isn't strictly incorrect, but probably makes everything more complicated than it needs to be.

The internal construction with LIKE '%...' is also not great:

Looking up identities by email address is improperly case-sensitive, because the query is a LIKE query against a binary column.

Here's a list of bugs I expect exist, although I haven't made it far as reproducing them yet:

We currently have bin/repository rebuild-identities, which takes a list of repository identifiers or --all. This has a lot of history in T12164 and we currently queue an "activity" for it during migrations in 20180809.repo_identities.activity.php.

I've marked D20905 as resolving this. This isn't really "resolved" completely, but T13454 has a better description of what the problems are and why they're difficult. Our behavior is, at least, substantially better than it was before.

On Ubuntu 14, the messages are a little less helpful:

This may also impact the Doorkeeper integration, which reads "id" fields from a few calls.

I'm planning to give Chrome some time to triage the report. If it sits there for a while or they decide it's how LayoutNG is going to handle this case, I'll look for workarounds. I don't think our intent/markup is totally unambiguous, and it may be reasonable to decide that this behavior is acceptable, even though Safari and Firefox have different behavior.

Here's a simple reproduction case:

I stopped the daemons, then created a new repository observed from GitHub with "Fetch Refs" set to "refs/heads/master". I ran bin/repository pull X --trace to update it, and saw it clone:

This looks like an edge case that fell out of D19864, which was originally motivated by similar goals (fixing how test notifications work).

In T550#202580, @epriestley wrote:

I'm planning to support this in the arc experimental branch, although initial support won't be optimized. We can look at ControlPath and/or adding batching to the protocol layer to improve performance once it works.

Layout looks very neat but a strange too with that big space gap between the icon on each row and the actual text in this case:

Yes sure. But in the case I've described above the user has access to diffusion (is member of the project having the diffusion application permission).

Isn't this working as designed? A user (or the public) needing access to the diffusion application in order to access repositories is exactly the behavior I would expect.