This does not describe a bug with Phabricator. See Contributing Bug Reports and Support Resources.

Actually, even GitHub exposes unrecognized email addresses directly in the page source, which is the same behavior we have:

Is this an actual problem you've experienced, or purely hypothetical?

I don't think this represents a real problem. This information is inherently public: pushing commits to a public repository makes this information public and easily retrievable by automated means.

I also might take a crack at fixing "human language diffs", I think I can get something which is worlds better than what we do right now pretty quickly (even if it isn't perfect) and it would be nice to be able to be smarter all over the place about communicating description/title changes and tailoring things for typo fixes, spelling mistakes and other minor edits. I think this is something we can get groundwork in place for and then improve gradually without needing to do any big rewrites or anything.

The logic around what we send to blog subscribers is a little goofy right now, and sends them the entire post content on every update.

Thanks, fixed.

Definitely, let me get you a rough cut.

It may also make sense to fold accents when normalizing strings for ngram indexes.

I think we fixed this elsewhere, yell if it's still an issue.

I tink at least some of this was added in, e.g., D14231.

You can destroy the whole index, then reindex everything.

We don't know how to reproduce this and haven't seen other reports.

I'm not sure how to reproduce this (it didn't reproduce just now), and haven't seen any other instances of it or further reports. It's possible this was fixed earlier this year; we did some work on inbound mail around the time of this report.

(Test.)

We haven't seen requests for this from other installs and I don't particularly favor this mechanism. Prior alerts in this vein like "daemon and web config differ" have created a lot of noise and little value. T7338 should eventually provide more monitoring tools.

I don't think we actually need, this at least for now. We can look at it again later if we get more feedback about users making these sorts of errors, but it seems unlikely (I think?) that a use would type google and expect it to work.

Let's just wait for a stronger use case before building this, I think our URL construction has generally become much stronger since this idea was originally tossed around.

I don't want the error messages to just disappear since I worry that might be confusing, but I've added an option to dismiss errors once you're done with them in D14886:

Couple of thoughts, not necessarily unbeta stuff:

Resolved by D14823.

I'm going to merge this into T8488 since I think we ended up just removing this distinction.

I'm just going to close this because it doesn't identify any specific problems and I don't want to build these things to deal with hypothetical problems.

I think it's good that destruction happens in the foreground, since I think this should be a very rare operation and errors should always be reported to the user. Users who want to background long destruction operations for some reason can use tools like screen.

These are in good shape technically for whatever you want to throw at them.

Maybe a better approach would be to let you filter which columns are visible more flexibly. It sounds like all the existing use cases are arising because "hide" isn't being used to archive obsolete columns, but because it's being used to give workboards multiple states where each state has a different set of visible columns.

See T5403 into T7858. I don't think this makes sense after T4100 with "Browse" UIs. All requests for this are "distinguish between multiple similarly-named projects", which is better done via "Browse".

Oh, I was thinking this needed a whole pile of work (like, all of T9372) but I don't think it actually does. I'll take a look.

The original request here seems to be for specific links to members and workboards from hovercards. I think it predates modern defaulting rules (i.e., clicking the tag now takes you to workboards for projects where they're in use) and we haven't seen other requests for this. I expect work adjacent to T10054 to continue giving us better behavior for clicking through. I don't understand the use case for frequently needing to access members quickly. I don't currently anticipate adding these links to hovercards.

Branches/tags ("RefCursors") have real PHIDs as of D14731, so that part is done, at least.