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.

Again, this issue is still relevant. Updating did again break it.