I think we're currently consistent about showing updated date (Diffusion, Differential, Maniphest, Phriction index view).

Hmm, I'm having trouble reproducing this. Here's what I did:

As above, we don't support installs that don't follow our guide.

I think this is fixed now (config change on the Mailgun upstream side). Let me know if you're still seeing issues.

Test v4

Alright, thanks. I'll bring up a test system with a more modern git.

Just to double check, does git merge-base e032e3606960 45936140fc3a in the working copy that you're trying to push print 45936140fc3a?

Thanks! We can just improve this error message, which should resolve the problem more directly.

If anyone has a reproduction case that they can test without undue disruption, try this patch against phabricator/?

It looks like this is expected to work without changes, but relies on some environmental variables being passed from the hook environment to the child environment.

The Git mailing list archives also aren't currently working for me (no DNS record for blog.gmane.org?) so I can't tell if there's any existing discussion of this.

This is likely the relevant change:

Thanks, that's extremely helpful. I think D16974 + D16975 should fix the bug (and an adjacent bug I hit while testing the first fix).

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

In the general case:

I'm pretty sure this this was just a straightforward fix that escaped detection for this long because any other repository edit would rebuild the index. D16972 rebuilds the index on any repository URI edit. Let us know if you're seeing issues after that. Thanks for the report!

We aren't interested in introducing complexity into Phabricator to work around limitations in GCloud SQL at this time. Instead, you should ask Google to fix this limitation with their service.

Does making any other edit to the repository (e.g., changing the description) correct the issue?

As far as I can tell, Amazon RDS allows configuration of sql_mode. Here's their announcement of support (from May 2016):

See also T7787 for plans to support existing !cc stuff from arc on the CLI.

(This doesn't really follow the rules as a feature request because it's just 35 copies of "other systems implement it so you should too", but I think it's something we would probably implement anyway sooner or later so I'm fine with keeping it open.)

Presuming this was resolved by D16967, let me know if there was more to be done.

Try putting MaxStartups 1024 in your /etc/ssh/sshd_config (or similar).

@csilvers, not sure if you got directed here from IRC. See also T11932. At HEAD, we'll now issue more explicit guidance about the required index rebuild.

Hmm, I'm guessing this wasn't clear from the workflow either, then?

Why did you allow everyone everyone edit the event?

Everyone can see from which url a calendar event came.

Please read Contributing Feature Requests carefully before filing a feature request.

If the only way to register is Google, it should be impossible to create more than one account per Google account.

Why is registration disabled?

This one is fine, I'm still going to fiddle with "in" too.

We haven't received more information about this in a few days, so I'm going to close it. Feel free to file a new request in the future, we just prefer not to keep requests open if they're outside of our control to move forward with.

We haven't ever experienced this, nor have we seen reports of users other than you experiencing it. This ("basically prevent the server from doing any other work") doesn't sound like a description of how properly configured servers are generally expected to work. My expectation of modern systems is that they have sophisticated schedulers which are largely fair in allocating resources and produce generally reasonable behavior, and this is consistent with my experience.

If this feature is valuable for you, I think you should implement it in your mail client rather than pursue implementation in every piece of software you use for work. A client-side solution could give you complete coverage with one implementation, and would be more powerful because it could perform additional filtering (e.g., allow important emails through even during off times, or deliver messages but not play an audio alert during off times, or ironically block family communication during work hours instead).

• Please report security issues via HackerOne.
• This isn't a valid bug report: it is missing required information. See Contributing Bug Reports.
• I can't reproduce this. Here's an HTML file which is properly escaped:

Feel free to file a new task when you encounter actual problems with real text and we can look at adjusting the limit, adding an additional block-level difference phase, rewriting PhutilEditDistanceMatrix in C (see T2312), or other approaches. We can make a better decision based on concrete examples of where the current solution is falling short than by guessing where issues might arise.

Here's the revised dialog after D16956:

I don't think that edit is always invalid: offhand, one reason you might want to make such an edit is so that you can add a tag to all events in a series, allowing you to query them so they can be exported to another calendar. Another case I could imagine is wanting to correct a mistake in the description of an event when you know nothing will be lost by editing future events (e.g., because you are the only user who can edit the event).

No.

(To answer your question more directly: yeah, no way to do pht() with variables in Javascript. We can build that without TOO much trouble, but I'd like to wait for a really good use case first.)

I do not plan to pursue any variation on points which can not be summed in a linear way. You can find some discussion under "Quantitative" in T4427#157820.

I'd say just get rid of it, or render "X / Y" without pht()?

• Availability cache build on All-Day events may be off, I didn't pick up a dot for E1222.

The panel was updated in D16806, on Nov 6. Upgrade Phabricator to see these changes.