("We don't want to do that just to make Phabricator work" is a completely reasonable response, but at least in this project this practice seems useful and we'd probably keep doing it even if branch information was more accessible.)

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.

When I turn on bucketing, I can't see it actually. Although I do have a lot of diffs, so it could have overheated.

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:

This seems to have fixed the issue. Thanks for the quick fix.

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.