This also seems weird to me.

See Planning (briefly: we don't know).

See also:

D14411 implements exact string matching, but I will leave this ticket open for support partial string matching as well. There are some technical considerations block this, see D14411#161139.

This is already prioritized, yes. See the weekly dev log for my plans through the end of the yar.

Sure, send me a diff.

Is this likely to be completed this year? We have some teams expressing interest in this feature and I might be able to convince management to get onboard with paid prioritization (although this ticket is also prioritorized right?)

PhabricatorFileChunkIterator does the stitching. Basically the flow is like this:

Can you point me at the code where the chunk stitching happens?

Ah yeah, that would be better.

Yep, this is good.

T5378 / D12692 also have some bearing here.

This should probably also wait for (or happen concurrently with / be considered alongside) the repository monogram changes which occur with T4245, although I think it doesn't limit the reasonable syntax available to us very much.

Determining the directories implied by the paths we find and injecting them into the list seems reasonable to me.

Could the server do the chunk stitching and stream the response to the client, rather than fetching it all up front?

Another alternative would be to mangle the commit message more heavily and strip out the fields we believe we can parse. So instead of showing something like this:

I think that would leave us with only two potential scale issues:

A possibly easier approach is to let the user just get an HTTP URI for the download (i.e. a normal, non-Conduit URI) and then call it in a standard way. Maybe by adding a needDownloadURIs parameter to file.info (or waiting for T7715 and adding it to file.query) -- the links are slightly expensive to generate because we have to do one-time token writes so it's probably better not to generate them by default.

Someone else ran into issues with Rocket Loader too, although everything broke completely for them in Chrome (although fine in Safari).

Yeah, I'm fine with putting a global lock on this. You shouldn't really ever be running it on multiple hosts simultaneously (in the best case, this just slows you down by running the slow checks in adjust multiple times), but it's dangerous enough to explicitly prevent.

@epriestley, I was thinking of implementing this as follows:

+1, although an alternative would be for Diffusion/Remarkup to render Reviewers: alincoln identically to Reviewers: @alincoln.

Happy to submit a patch if @epriestley is on board.

In T9718#143261, @chad wrote:

Have you never noticed the nautical patterns in Phabricator?

Scuttle?

Oh, I take the hosts offline first.

In T8348#143186, @nornagon wrote:

I'm also seeing this issue, even just using curl -d api.token=... https://phabricator.url/api/file.download

You can also whitelist MIME types in files.viewable-mime-types as a workaround.

See also T9161. You can use ./bin/mail volume to see how much mail people are actually receiving.

I can't reproduce the capital letter issue.

Presumably, he or she has a good reason for putting this policy in place. I'd recommend talking with them about it. Maybe they haven't thought about this case.

the people that should respond to those comments don't get notified

Couple of very minor hiccups with notify not having a completely clean deploy since it doesn't get pushed/expanded very often and was a bit out of date, but should be fixed now.

I've updated lb, alb and clb and the respective domains are now serving updated certificates.

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

Either is fine.

I don't think we need to auto-generate (and think it's slightly desirable not to -- I don't think we can do anything reasonable most of the time, and it will tend to make it harder to find a good alias when you actually want one if we do).

I do think we can get rid of this page now.

Some discussion in T7053. Mostly, I think it's just a ton of work to fix a problem that I think frequently (almost always?) boils down to users being out of their depth with server administration tasks.

So the CLI said "Go to this URL: XXX" and they didn't do that and instead went somewhere else that they remembered seeing before with the same name?

I think I'm just going to remove this check. The primary goal was to reduce support costs related to users not restarting daemons after changing mail config, but I think the net cost of users hitting it is larger than the net cost of users not restarting stuff was.

How did they end up there?

The ability to fork Pastes was removed in D14390.

4spoopy6me

le doot