New blogs element is great :3

Oh, there are only two options and neither would break this.

Is Settings → Diff Preferences → Show Unified Diffs set to "On Small Screens" (the default) for you?

D14747 should fix this. I haven't pushed that yet, but I updated all the changelogs.

The URI scheme changed but this shouldn't fatal. I'll fix the fatal and then go fix the links in the changelogs, there are only like 6 of them or something.

I think this should now be fixed in HEAD. Let us know if we missed anything, and thanks for the report.

It doesn't seem to work properly if I try to comment and also change the status of a task. The comment appears but the task status remains unchanged.

So you haven't actually reproduced this yourself? Is it possible that the user mistook xxxxx as uncensored credentials? Can you try reproducing it directly?

I should note that we're running the latest version of Git (2.6.3) which could be the culprit. From my superficial inspection of the code, it appears that the output of git fetch is simply reflected.

In your report, you say <user email address> -- is the login username for this user a string including "@"? Does the UI print out a message like this?

Until we have such a tool, you can revoke keys like this:

I think this is worth improving. However, I think it is not a very important feature in situations where things are set up reasonably well (not too many lint false positives, fairly fast tests or server-side CI), and that fixing these problems will have a lot of other benefits in cases where they aren't working well. That is, this should be more like a "nice-to-have" that saves you a few seconds once a week, not something you're hitting on >50% of revisions.

Can I set looks an intern on this?

Although timeline is now linked, I think feed still isn't linked?

What version of Phabricator are you running? (You can find this in Config → Versions for recent versions.)

Do you have the public key (or the private key), or do you just know which user has a compromised key but not know which key is compromised?

I can't reproduce that. Here's a search using "Path", which seems to work correctly:

This request does not describe a root problem.

I eventually got this live. blog.phacility.com is a little plain now, but seems to work fine:

@andrew-dixon Sorry, there's no secret internal tracker full of juicy updates that we're hiding from the public. If we haven't updated a task, there aren't any updates on it. See Planning for a little more discussion on this in general.

• Send rules upstream for now (like with the Korean rules).
• We'll probably make this modular eventually.

This has been in production for a while and seems to be working correctly. New rules are:

Closing this out since there's nothing actionable here.

I'm planning to just remove skin support in T9897.

Assuming this is in good shape now.

I believe this was fixed by D14511.

This was fixed in connection with T9825.

I can't reproduce this. Here's what I did:

Briefly, T9529 discusses some server-side system running on revisions that's live in your environment, presumably. Its current behavior is something like this:

T8378 discusses a milder case of this sort of thing but I think the logic here applies to it as well.

I think T8405 and this are both basically discussing the same use case, which I understand to be:

I think this behavior is reasonable as-is.

See Contributing Feature Requests. If you're aren't sure what we mean by a "root problem", see Describing Root Problems.

No idea how to reproduce, no other reports.

This behavior should be more reasonable at HEAD. In particular:

After D14737, we will now show this information in the UI if it's available. Here are the requirements:

This should be fixed at HEAD. Let us know if we missed anything or if you run into anything else. Thanks for the report!

Someone actually wants this, so I'll configure it during the deploy on Saturday.

Thanks for checking, that's quite helpful.

Ah. Yes, I agree.

I don't think that string is one of ours. Does it appear in flarc?

• -c seems to come from 1.7.2.
• --no-color and --color=never are probably two acceptable alternative methods for writing -c color.ui=never.
• --no-column seems to be an acceptable alternative for writing -c column.ui=never, but may not have existed until 1.7.11.