Source code thing.
One minor issue with this is that there's some duplication when the commit Fixes Txxx and the associated revision already has the edge (which is very common if the commit Fixes Txxx, because the revision almost always also Fixes Txxx):
To follow up on this:
I can't find any changelog in any version of Git which mentions the introduction of %B. The %B behavior was introduced in this commit in March, 2010:
Thu, Feb 13
Probably require PHP 5.4 regardless.
A problem in moving forward here is that we ultimately do very little complex data access in Phabricator, and what complex data access we do perform can often be faked. We likely have more use cases in Arcanist and provisioning code: API calls are slower, workflows are more parallel/interactive, and we can't just fake it all with AJAX.
Tue, Feb 4
Mon, Feb 3
I just wanted to hold it across the release cut, it's headed to master shortly.
@epriestley what's blocking landing this diff?
Thu, Jan 30
Sounds good. It felt slightly odd to me at first, too, but I think I also got used to it.
It wasn't a major UI issue to start with and yes, you get used to it. I would ignore.
The empty space means "this is a normal commit with no special audit state", and the column collapses if no commits have issues (see this task for an example). That seems fairly reasonable to me?
Jan 21 2020
The logic here appears to be that gc.auto is set to some value (by default: 6,700). If the number of loose objects exceeds this threshold (technically, if the number of loose objects in objects/17/ is more than 1/256th of this value), it triggers a repack (in a comment, git repack -d -l).
See PHI1613, where an install hit this warning (and resolved it by running git prune):
Jan 16 2020
Nov 25 2019
Nov 21 2019
Nov 19 2019
Nov 14 2019
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: