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

Just tried another and included the full output from arc land and the git merge-base:

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

The patch didn't appear to work for us.

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.

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

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!

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

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.

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.

(Also, I can't reproduce this.)

Generally there shouldn't bee a "New <object>" on edit object pages. I think this goes away with EditEngine.

• 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:

Thank you! The new dialog looks excellent, it would have prevented my error.

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).

Maybe it would also be sensible to not allow mass-edits to be triggered by past events. While it may be useful to tweak a single past event, I don't see much of a use case of updating all events starting from some past date. I'd argue that that is nearly always unintended.

Thank you very much, I'll take a look :)

Where can I find the major features list, any document?

That setup is not supported, and we already raise a setup warning making it clear that major features will not work until the base URI is configured.

Actually, I want use Phabricator on intranet( IP address, https://192.168.1.10/) and internet(https://somedomain.corp...) with different URL, so I keep it empty.
If this is not a bug, can you add this to the section:Troubleshooting in diffusion_hosting.

Why did you choose to ignore the warning, considering that it says "major features will not work properly" until you configure it?

Yes, but I don't know it's related to ssh service.
This problem spend me about 4 hours, I checked everything ...

When phabriator.base-uri is not configured, you should receive this setup warning:

Thanks @epriestley for the reply. Seems like my mental model of "prototypes" along with the misleading wording of "future" threw me off.

As far as I understand, E66 acts as a prototyp (or template), providing defaults for when the individual instances are "materialized" later, when they are edited. Is that correct?

Hi @epriestley, thank you for your explanation.

E1218 seems to have worked properly after the patch, at least.

I'm pretty sure D16937 fixes this, thanks for the report! Let us know if you're still seeing issues after that.

I think this should be fixed in HEAD now, but you may want to wait a few days to update (e.g., until stable promotes on Friday) since a few bugs related to T11044 have been cropping up since it landed a couple days ago.

Thanks for the lightning response!

Yeah, looks like that reproduced it. Here are the caches:

Hmm, can you try creating a test event on this install to see if you can reproduce it here? I played around with this a little bit locally but wasn't able to get it to break.

It's like before: Neither the orange thing appears nor am I listed as "busy" at my profile. I'm listed as available there.

Thanks for the report! I think D16924 should fix this, and one other issue that came up too. Both these are related to supporting multiple partitioned masters in connection with T11044.

This all seems reasonable, I'm actually not 100% sure what happened so I'll try to gather a better understanding of the situation ;)

The long-term fix is putting this stuff on EditEngine (some discussion in T11887) but this should be fixable in the short term.

I suspect this might be because the value for "Continue" is an empty string here: https://secure.phabricator.com/source/phabricator/browse/master/src/applications/harbormaster/customfield/HarbormasterBuildStepCoreCustomField.php$27 ; At least, changing that value to be non-empty seems to solve this.

Actually, I can reproduce this at HEAD using a HTTP request step.

None of your versions exist here, meaning you have some local changes which might cause this.; Can you reporoduce this on Phacility?

Generally, our behavior here is approximately the same as Calendar.app and Google Calendar. T11804 documents how various edge cases behave in those applications. I believe our behavior is no more spooky in any case I'm aware of.

Maybe this is a misinterpretation of "All Future Events"? That means "All events which start after this event starts", not "all events which have not yet occurred, considering the current time".

I'm still having trouble figuring out which past events were edited. Downstream has this query:

Oh, sorry, E66 would have been disconnected from past events by the edit. Let me look through the downstream task.

Assuming that's just a miscommunication, I can't immediately reproduce this locally:

E66 is the first event in the series, so I would expect editing E66 "All Future Events" to edit every event in the series: there are no past instances. Am I misunderstanding? What's an example of a past instance?