The patch didn't appear to work for us.

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.

I noticed that to, they haven't been working for a while. I have been trying to go through the http://marc.info/?l=git mail archive.

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:

We have been having a similar issue. Commits to all repositories are being rejected by the EVIL DRAGON BUREAUCRATS. We upgraded both Phabrictaor (Master) and GIT (2.11.0) as part of the maintenance window. In our setup with host repositiores in Diffusion, using SSH.

This happened to me yesterday too. I am using the stable branch. The only thing that changed that I upgraded git to the latest release 2.11.0.
I have tried to change to the master branch which did not solve the problem. The problem was solved then by downgrading git to 2.10.2.

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:

Attached is a single VEVENT that causes "Datetime has no timezone or viewer timezone." in the calendar view after importing, the import itself runs fine.

In the general case:

Getting Datetime has no timezone or viewer timezone when viewing the main calendar.(https://gist.github.com/carlokok/570d524fe2a6dd1472835c0fa67b7faf) after import. Since the import contains a quite a bit of private data, how can I narrow down which record specifically it fails on?

@epriestley Thanks, that's fixed it! I'd not looked index engines at all before, so wasn't sure if I was just missing something stupid on that side.

PHP 7.1.0 has been released yesterday, and among the changes;

Absolutely makes sense - provided some more background on the problem. Looking forward to hearing your thoughts.

Basically, if this request is just a suggestion, we'll probably pass on accepting it (see Hypotheticals). But if people are frequently having issues (we haven't seen this) please give us more details on the workflow, etc, people are tripping up on. I don't think just adding the word "Git" somewhere will necessarily solve any core problem since people are not likely to read, for instance.

Ok, appreciate the feedback - I'll try to tackle it in a bit more detail.

We only take feature requests that state root problems, see Contributing Feature Requests and Describing Root Problems.

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!

From what I understand it's something Google is working on. I've been dealing with the limitations myself for a while and it sucks, but hopefully it'll be fixed on their end sooner rather than later.

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?

Specifically I'm looking at GCloud SQL, which does not yet allow you to use config options that require system-level changes. You can still use a dedicated SQL GCE instance, but using the managed SQL itself isn't yet possible without running into errors about the sql_mode.

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

I'm in the same situation. This would be a great addition.

OK, this is interesting: having tried reproducing it on a test Phacility instance, it works as expected there. Perhaps one difference is that my local installations don't have Diffusion serving repositories itself over, e.g., SSH? These repositories do not have any URIs other than a remote Git URI which Diffusion is observing.

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.

It makes sense in retrospect, but not from the workflow no.

Thank you! I'll do that and report back.

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

My management would like to flag Commits for Audit if they either don't have an accepted Revision (already have this setup in Herald) OR they have failed Harbormaster Builds. We're not terribly interested in notifications/emails for this. This use case seems a bit different than others discussed above.

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

My apologies. I read over that bit and presumed it meant edit the calendar items

Why did you allow everyone everyone edit the event?

In T11816#202107, @epriestley wrote:

Everyone can see from which url a calendar event came.

This isn't expected. Can you give me reproduction steps for this?

Everyone can see from which url a calendar event came.

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

My only concern with the current ics importing is that the url for importing from google, owncloud/nextcloud usually contains secrets other users shouldn't see, like in the case of owncloud: un/pw. Everyone can see from which url a calendar event came.

did anyone fix this issue?

Same problem here. A way around this problem is to not re-use panels: Creating a completely new panel is adding it only once, however picking an existing panel is adding it twice.