Thanks for clarifying

The section in T11922 only applies to the storage engine portion of that change, not to reindexing in general, and dropping the index is likely to hurt things overall if we need to do this more in the future (no performance improvement but totally nukes the search index until the reindex occurs).

Should the description here include the section from T11922 about minimizing downtime? The release notes link to T11922 and not here, but someone from IRC had been going based on the information in this task without seeing that note which may have saved them some indexing time.

Cool. For context, stuff I expect to do upstream, sooner or later, since I consider it unambiguously good (just not necessarily high priority):

This seems like a good plan to me, we're just checking in that this isn't totally outside the realm of possibility while we plan some super secret changes to our instance.

Can you outline the attack scenario or scenarios you're concerned about?

Good enough for me.

I don't see any ideas worth pursuing here unless we get evidence the confusion is more widespread.

It doesn't happen frequently but I occasionally am looking for a recent change and use the field to narrow down where I'm looking (usually something like a change made in the past 3-6 months). Having the date field displayed in that case helps to know when I can stop scrolling/paging. Since the last updated date very often is near the created date I think it helps in most cases, but the scenario I came across with this task was that some older things had appeared towards the top because I added some commit <-> revision references recently.

(I don't consider is a bug: we're consistent about showing modified date across all applications which show a date, as far as I can tell, and omitting a label is a product decision.)

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:

wrong phabricator

This issue is now fixed in the Docker image, which now uses an older version of Git and checks to ensure that it does not install 2.11 when the image is being prepared. If you're affected by this issue, run docker pull hachque/phabricator.

Brilliant! As T11940 mentions, downgrading to git 2.10.2 fixes the problem. Thanks guys.

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

Hi Chad, thanks for the quick response. That's unfortunate, I use to run setup using the "Installation Guide" a while back. That server died a few months ago and I decided to docker everything. My previous setup use to check for updates every 30 minutes and I never had any issues. Thus, I let this docker update every time it restarts, probably shouldn't have done that. :)

You're welcome to spin up a test instance on Phacility or do a installation from our guide, but we don't accept bug reports that include "use third party installer" to reproduce.

For reference, xhprof will not be included in Debian Stretch due to lack of PHP7 support: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846138

Thansk

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

Test v4

Sorry I accidentally hit Ctrl+Enter and submitted before completing the form

Damn, that was fast! This should be a perfect solution - thank you for your help.

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.

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.