Generators can't "return" until PHP 7:

In T11968#251717, @epriestley wrote:

XHPAST currently can't build an AST for $result = yield ..., even though this is a valid construct. This is probably a straightforward fix.

XHPAST currently can't build an AST for $result = yield ..., even though this is a valid construct. This is probably a straightforward fix.

Does using --max-pack-size to reduce the maximum packfile size really let Git "checkpoint" after each packfile, so the process is effectively resumable?

PHI1655 identifies a specific case where enormous packfiles may create problems:

I have some code which runs and looks plausible (i.e., not covered in piles of callback garbage), at least:

Here's an actual example of loadHardpoints($objects, $hardpoint):

In the specific case of the Hardpoints, we currently often have code which loads objects but doesn't do anything with them. For example, most Query classes use didFilterResults() to fill things-that-sure-look-like-hardpoints, but few do anything with the results.

The core idea in D5104 + D5105 is that $future->resolve() and id(new FutureIterator(array($future)))->next() (like, roughly) execute meaningfully different code paths.

Somewhere in experimental or wilds, I introduced ArcanistConduitEngine. This has some weird fake future stuff going on, so this is probably now ripe.

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:

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.

I just wanted to hold it across the release cut, it's headed to master shortly.

@epriestley what's blocking landing this diff?

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?

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):

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 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:

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.