This is somewhat difficult because querying which branches a commit appears on is slow (in some cases, extremely slow; see T9898), and it is difficult to cache because a small write (pushing one new branch) can change the branches that millions of commits appear on. For example, if I do this:

Yeah, the user is struck through because they are "closed", which is because they are a bot. This isn't the best way to deal with this, but it dates from early 2014 (D8231) when everything was simpler.

Just kicking this out of Search since it's really Phriction specific.

This has been live for nearly two weeks without anything apparently exploding so we don't have any further acton planned upstream (although see T12450 for some followups). If you do run into issues, feel free to file new tasks describing them.

This has been open for about two years without a significant amount of additional confusion or interest, so I don't currently plan to change it.

I'm just going to merge this into T8646 which broadly discusses richer search results.

DiffusionSSHWorkflow->execute() currently makes a proxying decision before it determines if a request is a read or write request. This needs to be reworked before we can support separate flags, since the host we'd choose to proxy the request will vary if only some hosts are readable/writable.

(For reference, see discussion elsewhere.)

My intended fix here is:

Running multiple different versions of Phabricator on a single host is not currently supported. We should probably handle this situation better than we do, and there is no technical reason we can't support this, but this use case is very rare.

How about "i" for "image"?

I am also keeping an eye on https://www.reddit.com/r/bonehurtingjuice/. It's still a small meme but if it takes off we're all going to be drinking bone hurting juice this time next month.

Also our meme format is very outdated, the new meme format is:

This should be fixed at HEAD of master, thanks for the report!

D17656 is legitimately pretty hacky so this is now entangled with T11110, etc.

This is a legitimate bug but I think it's very long-standing and fixing it requires doing a lot of extra data loading to get the current diff PHID. Until someone else notices, I'd rather wait for diff PHIDs to be denormalized onto revisions.

This is a sort-of-intended result of several different rules colliding to make a mess. Here's the primary rule:

This should be fixed by D17654 and available at HEAD of master and stable. Thanks for the report!

This is technically supported, but not easy to find in the UI right now. Here's an example:

This reproduces for me locally. (??!?)

A small subset of instances were queried with this script (below) to assess the impact/priority of T12137. This script examines fulltext search queries, but the only output is a ratio of potentially affected, unique queries first issued in the last 30 days, like this:

This is currently expected, although we could consider changing it.

You should have sweeping janitorial powers as a member of Community now.

It looks like before step (2), jmeador can only accept for one reviewer (the package), since he's already accepted for himself. The current rule is:

T12531: Unable to upload file: failed to read 4583864320 bytes after offset 0 discusses one side effect of these changes, it should be fixed in HEAD of master and stable now.

Thanks for that catch in D17651, let me know if you're still seeing issues after updating. I'll cherry-pick that to stable too.

Yeah, that looks like it's consistent with the hypothesis above. I expect:

Yeah, pretty sure what's happening is:

See also T12532 for related work.

I think the first error is causing (maybe?) the chunk engine to fail, so we're falling back to the "upload the entire file in one shot" engine, which ain't great on 4GB files.

Alright, let me take a look. That exception is pretty specific and it may be obvious from the code.

(Actually maybe you need a 9MB file.)

Does this reproduce with a 5MB file?