i should have kept a helper function in, but was worried we'd never find the callsites.

The reason we suggest @ as a delimiter is that you don't have to escape forward slashes if you use a delimiter other than /, so you get a more readable regexp.

I think I'm going insane. I was wrangling with that for ages and as you pointed out /\.js$/ does in fact work. I have no idea how I did every permutations of that regex except that one.

Hello
I agree with @richardvanvelzen this is very very useful option.
Especially in scenarios like this, for people that like to have important tasks open in tabs.

Hi, we're still strugling with this issue, anybody had to deal with this already ? Is there a plan on optimizing commit parsing and daemons scalability ?

I believe this is fine; I can't immediately come up with an attack using -.

Form (1) is expected to work, which is why we don't document a need for form (7): one is not expected to exist. If form (1) does not work, this is a bug with Herald itself, not with the Herald documentation.

Both of those options are locked in the UI. "This configuration is locked and can not be edited from the web interface. Use ./bin/config in phabricator/ to edit it." I know the basic syntax is phabricator/ $ ./bin/config set <key> <value>, is it just a case of

It's fairly straight forward to add your own linter extensions as well, the only thing that becomes difficult if how you distribute them. Upstream doesn't help with this at all but you should be able to figure it out from the wiki if you have a need for them.

Thanks for the report. This should be fixed in HEAD of master, and fixed in production some time in the next 24 hours when the docs regenerate.

Those changes add a fairly coarse disk-based cache here for use by the CLI. I expect it to shed ~95% of the load and make the admin tier stop glowing white-hot 24/7.

Follow PhabricatorSearchEngineExtension or similar.

If you only knew how lucky you are to have Evan explain this to you rather than trolling through grep -Rn "PhutilClassMapQuery" * --include \*.php errday.

(The second step is because some types of attachments work on multiple object types, and you could even conceivably write an "edge" attachment here that just works for anything and returns all edges, although I'm not confident that doing so isn't a major security problem.)

I think you've already written these, but the budget walkthrough is:

Live, armed, pre-commit A/B testing is unambiguously the most exciting part of our jobs.

For the record, I strongly endorse autopatching unreviewed code onto live, armed, autonomous combat vehicles.

Internal attachment is definitely the shortest path. Whatever we end up with is likely to look very similar to the naive version, and you can keep your attachment running after we offer an "edges" attachment, so there shouldn't be any real transition cost.

Should we implement this as an internal search attachment in the meantime? Or is there a possible pathway for @jcox to get something like this working in ~3 days?

This is basically a special case of T5873.

I'm thinking we just create a search attachment for maniphest.search which contains diff PHIDs.

Probably a bug. I spent like 5 minutes trying to get that field to work, inspecting the db, rebuilding search, etc, and link field never seems to get indexed.

Any thoughts? If it sounds like a real bug I'll file a report.
(meant to add this as a comment, but accidentally added an answer)

Found some shorter repro steps:

Ahh okay. I understand now. That did indeed happen automatically.

If you give a Phurl an "Alias", you can type ((thatalias)) in Remarkup to reference it. For example:

Also the ((alias)) syntax should use the most-preferred URI, although I think that will happen automatically.

I added a note about this to T7338 for the longer term.

That should really have been in a day 1 "spend 10 minutes doing this stuff first" document, I started collecting this stuff in T11561.

Also, are prototype applications enabled (phabricator.show-prototypes)? If not, Phurl won't actually be installed.

Alternate/simpler test is "does /phurl/ work".

Also, are prototype applications enabled (phabricator.show-prototypes)? If not, Phurl won't actually be installed.

Ah, okay. I'm not immediately sure, then -- did you restart Apache / is /config/edit/phurl.short-uri/ picking up the change?

I suppose we could link to /config/module/site/, which has a list of all Sites, but it's probably not intuitively obvious from there what's going on. It's also possible in some future world to reach this screen without running Phabricator at all (T1806), although probably unlikely.

Oh I left out the fact that I had already configured phurl.short-uri but still get the "Site Not Found" message.

First screen is good.

Just want to sanity check this before I continue. I set the ServerAlias and started getting this page when visiting short.url.com:

I've updated both hosts and manually fixed D16464 to display the correct changes.

Yeah, I just neglected to push secure002 when I pushed secure001. I'll fix this shortly.

Oh, this looks like a smoking gun:

There's no changeset in the database, so this isn't just a weird permissions issue -- legitimately, no changeset was extracted.

bin/differential extract rPHU491ebc74d816dbe2fc8bbbbc992e8a14f8c613be also extracts the change correctly:

This might actually something more narrowly scoped since, e.g., D16468, D16469, and D16470 worked fine.

Thanks @chad. I would say it's the same for the visibility part, but not for the filtering support by custom fields.

Ah, yeah. If you're using Apache with <VirtualHost /> directives, try something like this?