I'm not immediately able to reproduce this. Here's what I did:

Why does the mail say you received it, see /mail/

From elsewhere:

We have updated to Git 2.11 and updated to master pull/push works for us. Thank you as always. :)

In T3179#198521, @michelkaeser wrote:

In T3179#142498, @lfarkas wrote:

Trac wiki import to Phabricator's Phriction.

Based on svemir's anser in https://secure.phabricator.com/Q12 a not to nice not perfect but more then nothing:

https://github.com/lfarkas/phabricator/blob/master/scripts/util/trac_wiki_import.php

@lfarkas the Github link results in a 404. Do you still have a copy of this script? I am in need of a Trac Wiki importer and yours seems the only one available. Or does anyone else have a working script?

Thanks in advance.

I believe this is now resolved at HEAD of master. Let us know if you're still seeing issues after updating.

Hi folks,

I believe HEAD of master can now accept IPv6 requests, with the caveat that most of my testing has been at least somewhat synthetic and I haven't set up a legitimate, dedicated, IPv6-only host anywhere to be certain it works. That said, I'm reasonably confident that my synthetic testing was fairly thorough, since not very much code really cares about the remote address and I was able to make legitimate requests to ::1 over HTTP and SSH, and from synthetic IPv6 remote addresses. If you run into issues with sending IPv6 requests to Phabricator, let us know.

I'm planning to support this in the arc experimental branch, although initial support won't be optimized. We can look at ControlPath and/or adding batching to the protocol layer to improve performance once it works.

I'm going to merge this into T550 since it sounds like that's the immediate way forward, at least.

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?