Task creation slightly ahead of HEAD through maniphest.edit now hit essentially the exact same code as the web UI, and no longer appear to do this "[Reopened]" stuff.

This hasn't hit HEAD yet, but will be resolved indirectly as part of changes in connection with T9132 shortly as that rolls out.

See T4103 (or create a wiki page or dashboard).

I'm removing this "Create Project" workflow entirely in connection with T9132, obsoleting this task.

This is now fairly easy to implement and the race stuff isn't a problem anymore, but I'm not sure it's worthwhile from a product perspective. We could pursue these things fairly easily now:

See T4200.

I think this is mostly either resolved or obsoleted by "Email Commands" (Help → Email Commands in Maniphest). We also backed away from hashtags implying project associations, and that seems like it was a good call.

We haven't seen other use cases for this. OAuth or Nuance are more likely approaches from an upstream viewpoint.

Actually, you probably also don't really care about removing the comment event anyway, since it can't change policies and you can't comment on objects when creating them, and I think your listener doesn't actually end up doing anything special for the actions that are available? So this might be mostly moot anyway, but in an ideal world I'll get through the main "edit" event shortly too.

Quick update here: ApplicationEditor/EditEngine have caught up with this, so the current plan is to indirectly remove this event in at least some cases (currently: changes made from the "Comments" area) after the stable cut on Saturday. You can upgrade to this week's stable safely but we should make sure things are in a good place before you move beyond that.

pretty big rough edges for the workflows it intends to enable

I think there are two issues here:

I think this is a problem only with the default font, it seems OK in other fonts:

I think the first SSH connection is still more expensive than several HTTP connections, and we can't easily just pool all traffic from a host over a single connection because a host may run multiple instances of Phabricator -- and we already built all the HTTP stuff anyway.

(I think that --not construct is wrong, and we'd just have to enumerate every branch explicitly.)

It's also possible that we can run git log --all --format='%H %P' and git for-each-ref and implement --contains ourselves in less than 2 seconds in PHP, although this is hugely ridiculous and clearly a problem with Git if true.

If you run those commands on their own, they're also slow? Even just this?

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

Yeah, let me dig into that a bit and come up with some options. I have to go look at what the skin code is doing.

I don't think it costs us very much to keep it around, and it does make some stuff nicer/easier. For example, we'd have no way to link to the live blog or live post if we don't know what domain it's on, and I like checking the live post after publishing something.

Some thoughts from banging on this, not sure how much you want to deal with:

It would be helpful to understand how to reproduce this. Specifically, I think what's happening is something like this:

I'm just going to close this, I can dig it up later if I want to reference it.

This is basically all reasonable but entangled with the giant mess in T5791 and T9161.

Broadly, to set expectations, this is a very low priority for the upstream and neither of us really have any familiarity with Elasticsearch, so I don't expect to move this forward for a long time.

We don't currently support ElasticSearch 2.0. I'm collecting issues we've seen with it in T9893.

As an alternative, I'd like to consider dropping upstream support for ElasticSearch entirely. We originally implemented it because Facebook wanted it and the project was more willing to implement and maintain things. However:

@ru31337, that issue isn't related to this one and isn't "wontfix". Please see Contributing Bug Reports for instructions on how to report bugs. Choosing an existing similar task, changing it to "wontfix" and dumping your issue into it won't get it fixed.

I don't think telling users that their filenames must match a complicated regexp and expecting them to figure it out is a reasonable behavior for a linter to have. I think I'm fairly comfortable with regular expressions and not confident I could figure out what the message meant quickly, and I know at least some engineers just don't have regexp literacy as part of their toolset.

I suppose the "version number" I propose is a little tricky, because it won't be incremented if a user edits a comment -- this does not apply a new transaction. We could use a <MAX(transactionID), MAX(commentID)> version instead to catch edits.

Ah! That could definitely explain it.

See also T9515 and T7639 for "choose some other users to trust, if you lose your phone they can vote to strip your MFA".

This was an intentional change in response to requests by other users in T4333 and elsewhere.

There isn't really one, all the applications that do it right are doing comments, and you can't do the same thing they're doing very easily. Audit does something but it's a mess. It should really just get restructured, I think.

I've marked D14637 as fixing this.