(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?

Here's the first part of a trace of an arc diff for me (includes most of
the pre-commit-message work):

this repros reliably for me - 100% of the time.

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

I am getting the exact same issue.
I am prompted for a user id and password so I use the appropriate ones:
user: user_name_in_phab
password: users_password_in_phab

In T9441#146736, @franshamk wrote:

+1 for cygwin/babun support.

+1 for cygwin/babun support.

For Home I expect 90%-98% of people to not be blog post authors, so visiting /phame/ would be best served getting content to them from whatever Blogs they want to follow. I am partial to providing to quicker access to posting new posts though, so I want to think about that some more (and EditEngine might be the actual answer).

DocumentPro is way better than Oblivious

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.

Oblivious skin is terrible and we should just get rid of it. The internal skin is a million times better.

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.

Do you see any point to doing "Custom Domain" stuff? That is, with EditEngine and Conduit, should that use case just be on the end user?

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

Is this a generic "notify users about failed builds" ticket, or a request for "webhook about build status"?

I'll see if I can come up with a reproduction case.

Specifically, we need full steps to reproduce the issue. These need to be, from start to finish, full steps any engineer either one day or one year from now can follow and achieve the same error:
https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#include-reproduction-ste

This ticket doesn't provide steps to reproduce the issue. Is Contributing Bug Reports unclear on this matter? Can we provide better documentation somehow?

Thanks for the reply. I have downgraded Elasticsearch to 1.7.2 still it not working. Now it shows as "Loading..." rather than getting "No Data".

Thanks for the reply. I have downgraded Elasticsearch to 1.7.2 still it not working. Now it shows as "Loading..." rather than getting "No Data".

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.

Hi, a co-worker of @vintrax here.
It seems this happened because I messed up. I wrote a bot that accidentally left hundreds of comments in a single task in the span of 20 minutes. The large amount of comments caused both the a lot of search index jobs to be slow (DELETEs/UPDATEs on a big MYSQL record) and big in amount (an index job per comment). To top it off these jobs couldn't be run in parallel efficiently because of search_documentfield table locks (because it's MyISAM). This caused the queue to still be clogged more than 24 hours after the 'bot mishap' happened, which is why I initially did not think this had caused the issues