FWIW I think this is pretty genius. Especially the repro-or-it-didn't-happen aspect.

Just as a side note: PHP 7.1.2 was released like a week ago, and I have not seen any more spurious segfaults on my instances when doing imports or anything like that on the server. The arc liberate bug remains dead and I have not seen any more faults in arc either. Builds should now be available in most PHP 7.1 repositories (in multiple distros/systems), so I suggest an upgrade for anyone who's affected.

Yeah I'll take it, pretty sure it's my fault.

Yeah I was planning on bisecting, but sounds like you're claiming this?

I think this is probbbbbbbably an actual bug unless I'm totally out of it -- possibly my fault from D17372.

I realise this is a wontfix, but you kept asking for root problems.

@epriestley The import has finished, but some commits show as importing still?

We have a hosted instance and seem to be running into the same issue. How do we get this going in this case? (Warning: we are new to phab!)

Agreed this dialog is pretty annoying.

No.

@epriestley Would you guys be willing to accept a patch that implements this?

I could be wrong

Also, note that in this install, Create Form links to /transactions/editengine/maniphest.task/edit/nocreate/, not to /transactions/editengine/transactions.editengine.config/edit/nocreate/. So, to the correct place, but "forbidden" one.
And there is simply no any other button to push.

This also seems related: https://secure.phabricator.com/D17262

Yep. How do I create the form I need then?

This isn't a bug, but is confusing.

Removed apache settings:

<LocationMatch "\.(?i:os)$">
    ForceType application/octet-stream
    Header set Content-Disposition attachment
</LocationMatch>

I don't believe we've seen this pop up again. I can't be certain because right now all the log files are empty, but that means the errors went away?

I believe this is effectively resolved now -- we're running all the daemons on multiple hosts on secure. There's remaining followup work (T6768, T6615, T10753, T10754) but I think the core is in reasonable shape.

T11708 has almost nothing to do with this, but the fix for this will rewrite the code that's running into issues and probably moot them.

I'm just going to merge this into T12115, which isn't really related, but will rewrite this code and probably "fix" this, since a reproduction case seems elusive.

This could probably be built with RRULEs now, but we don't currently have use cases / plans around a general-purpose cron-like tool.

Use cases seem to be fairly well covered now.

This is 2+ years old and autoscaling probably covers it now. T5401 is probably a more tangible attack on this.

This got a little more work when clustering was written but it's essentially a log of two-year-old ghost sightings at this point and not actionable.

I guess this one can live for now since that's reproducible/actionable.

Probably a dupe of T11708? I'm just going to kill this one since it's old as dirt.

I believe this was likely resolved by D16460. This (binary transport over Conduit) is still a problem in general, and T5955 is the general remedy, but diffusion.rawdiffquery specifically now returns data via Files.

I think it is likely that this was resolved by D17123. If it wasn't, we don't have a reproduction case anyway so we can't move forward. I'm going to call this one dead until more information turns up.

We were never able to reproduce this convincingly and as far as we know the reporting install no longer uses Phabricator, so I'm going to close this out.

I believe I have the first part of this (restructuring the code into a more sensible Overseer > Pool > Daemon sort of thing) working, but it could use more testing. I'm going to see if we have anything else in Daemons that I can fix while I'm here to help me kick the tires a bit.

You can make your own extension to Remarkup to allow auto-linking. I have one setup which I based off of P1129, P1209 which regex matches on Task-xxxx and uses the xxxx to link to our system. That works well and is sufficient for what we need.

This request doesn't describe a root problem, just suggests we do about a thousand hours of work integrating with remote APIs. See Describing Root Problems.

Some possible approaches here:

There's also a bunch of the usual free-tier shenanigans on this host -- free instances with 1 user importing multiple large repositories -- but that's to be expected.

Here's an attempt to manually classify recent feature requests. I'm not sure how much value we're really getting out of this channel except from users who are already part of Community:

Unfortunately, we haven't received enough information on this to move forward. See Contributing Feature Requests and Contributing Bug Reports if you'd like to try filing a new request.

Can I make a question?

1. Install Phabricator at the version noted above.
2. Import a GIT repository via observing a URI.
3. Note the reference HEAD -> master link broken on latest commit.

Please provide reproduction steps, we don't accept bug reports that ask us to go look at their server.

Hi I recently started experimenting with phabricator with my team and stumbled on this issue.

The in-diff issue is described in T11482.

We once rendered these renames like this:

new/path/to/file.c
  Moved From: old/path/to/file.c

Personally I like that, I think a compromise to make it easier to consume, would be to try and group the moves together and showing the relation, for example
now:

a ->
b ->
a <-
b <-

to

a ->
a <-
b ->
b <-

I'm not sure I understand what changes you're suggesting.