Request reopen, based on my above comment.

This does not contradict T5474, but compliments it. Both tickets are required to provide seamless operation

Awwwww yissssssss, looks like PHP 7.1.2 RC1 fixes it! Using the Fedora 25 "PHP 7.1 Remi Testing" repository, 7.1.2 just completely finished a run of arc liberate on Phabricator without problem.

Yeah, the sury repository is the one maintained by one of the PHP devs. I think if you just do something like apt remove php71* or apt remove php7.1* you can just reinstall all the php5.6 packages and you'll be dandy, at least as far as arc is concerned. They're all in the same repo, just separated by version suffix.

I updated to test this bug. I'll have to roll back if I need to add a new class.

Just curious -- did you just notice this, or did you upgrade just to test this bug? If it was the first, that's an interesting data point! (that arc liberate is less common than I expected)

a devastating self-own. we've all owned ourselves.

well i've ruined my dev environment now...

Yup, that's the one @chad. I haven't tracked it down any further with strace or anything -- but if you try running that phutil_symbols.php command a billion times, note it doesn't fail every time, or possibly even at all (try like, for x in $(seq 1 1000); do php ... >/dev/null; echo $?; done | grep 1 or something). But if you run arc liberate again, it *will* fail every time, just on a different file, at a different point.

xhprof isn't needed to reproduce this; it's xhpast that's involved. Maybe. (xhpast is just a simple bison/flex parser/lexer combo so it isn't dependent on PHP internals in any way, and it's what drives the module parsing, etc)

like this:

T9805?

i like that dog's hat. it's a good hat.

We need a neologism for "bad workaround".

(A "workaround" is to not use dashboards, but we'll fix this soon.)

Ah, cool -- thanks!

See T12174 -- this is an issue with the new embedded-on-Home dashboards.

Please file a bug report with the steps we can follow to reproduce what your seeing. I still can't follow what I need to do here to see this locally.

1. If I remove a user from our internal group (Project: contain internal members), I receive the error above.
2. The internal group is only visible to its members (explains the "restricted project")
3. Removing the "visible to" restriction, displays Projektname in error message

I see, it must be a text file.

Safari / OSX:

word-break: break-all; seems to be working fine.

I can't reproduce this, is there a specific browser/OS I should test? Also, feel free to upload a test file to rGITTEST

That sounds good to me.

I think it would be reasonable to treat this field as remarkup (at least, internally -- probably no bulky UI) so we end up generating a mention on the task. I have similar reservations about making "fixes X" start performing magic in surprising contexts.

The linked file was used for testing this bug in a repeatable way. Based on some internal testing my (very rough) estimate is that this occurs with commits that are at least above the 750MB mark. I haven't tested below this size, but some more debugging could be done to try and find the limit and to confirm that it's related to commit sizes rather than some other metric like time.

Thanks!

It won't close the task, but they will be connected.

There is a tangental path forward with T1894, which if we add comments there, and you mention the task, an association should get made back to the task.

Probably will implement in Badges and see how it goes. I'd mildly agree with your (only) mild concern about mild confusion if admins do a poor job labeling stuff.

I have an infrastructure project that mostly involves writing/updating documentation. It is somewhat of a hassle because while closing the task when it is done is not usually a problem, I have found that it is not common for people make their way over to a task after updating the documentation to comment on it (when the task is still not yet ready to be closed).

This is an very specific feature request. I can't imagine anyone knowing about it, expecting it, or using it other than yourself. This would also be exceedingly cumbersome to build and maintain.

Going to merge into T6117 for completeness. Mostly, I don't think re-ordering here is helpful and will probably explore alternatives first. I also want to add "whiteboxing" to the auth page as well to allow people to customize the login page to their organization, so that should be considered during that overhaul as well.

Also, this would be along the same principle as to why Maniphest allows you to reorder columns, speed and efficiency. On my laptop, I am required to scroll to hit the login button for LDAP, whereas if it is reordered then I don't need to scroll.

The problem of not being able to reorder providers is when logging in, users (most anyways) will normally gravitate to the first login box they see to attempt to login and not actually pay attention to additional login forms that are available.

The root problem sounds like users are confused by the UI, which can have multiple resolutions.

Why is that a problem?

Root problem would be it is not possible to currently reorder or hide authentication providers login forms from within the configuration on the main authentication page.

Please see Contributing Feature Requests for what we need in a feature request. Specifically this is missing a root problem, which is our bar for accepting requests.

Also I very probably meant "inline comment" and not "inline diff"

Oh, I missed "inline". That reproduces for me. I'll file a separate issue.

I do not have persistent chat open.

Do you have persistent chat open?

I came across a small bug with the "auto-suggest" feature. In differential I was writing an inline diff, and ended with :/ to show my face in plain ascii, and hit ⌘+⏎ immediately after to complete my inline diff. After typing :/ the auto-complete popped up and when I saved the draft with ⌘+⏎ it forever immortalized the auto-complete popup on screen with no seeming way to get rid of it (refreshing probably fixes~). I can reproduce on this install.

It says restricted application and only members of a certain project. Do you have steps I can reproduce the bug locally. I can't reverse guess here offhand how you've configured your instance to get here.