We can clean this up for phortune a bit better.

This is the expected method.

BTW is the print action the expected method to get an "invoice" for my records? Or can you download a formal invoice from somewhere?

It has the visible effect of removing the page header and footer.

The heuristic only triggers if the repository was previously empty. So it might possibly get a false positive on the very first pull request to a new empty repository, but should be fine after that.

@epriestley Is there a way to disable T9554's heuristics? With patchsets of 30+ patches which get pushed in a single atomic bundle, we don't want to go back to import mode and lose all notifications.

@epriestley Thanks for the thorough response. I guess it's probably been fixed in intermediate revisions, and as you say, it is all changing pretty dramatically anyway, so no big deal: as it was a newly-created repository, I just scrapped it and created anew.

Note that when you do this, you may generate a large amount of email you don't want, because you're adding commits to a repository which was previously marked as fully imported (it "completed" the import process when it was an empty, hosted repository). You may want to disable publishing in "Publish/Notify". See also T9554.

I can't reproduce this. Here's what I tried. First, I created a new, empty, hosted Git repository:

If you know the ID/monogram of the room (should be in the subject of any email you received, looks like Z123), I think you can also bin/policy unlock Zxxx it, which should make it public. Then you should be able to rejoin it.

Hm, Problem solved:
In my case there has been ServerName FooAddress defined in the default-server.conf while my vhost for Phabricator was configured to ServerName FooAddress.FullAddress.com. It seems as if Phabricator then was jumping between those two addresses?

I'm sorry for bringing this up again - I've got the exact same problem and there's nowhere else to discuss the issue.

@avivey Turning off the autoclose feature, fixed the error. I'm fine with this. Thanks for the pointer!

you can likely manually modify the conference_participant table in ${NAMESPACE}_conpherence. The structure is straightforward.
This is likely not a good idea to do on a regular basis.

Interestingly, if I cut and paste the whole command (Over 4200 hashes) on the command line, it works fine (I think my command line limit is at 2MB on Ubuntu 14.4).

OK, I was able to reproduce this; The key is to have 1000s of autoclose branches.

does ./repository update work for the smaller repo?
I don't think that's an issue with the length of the command (I'd expect a different exit code - 126, and I think our command execution bypasses this limitation). Exit code 127 might mean that when you invoke it in this way, it can't find git.

How many branches/tags in the large repository?

Closing this as it's not a bug. General feedback is fine on T10349

Thanks. I'll upgrade then.

This should be fixed in Week 17. See T8952 / D15773. Let us know if you're still seeing issues after upgrading, or can reproduce the problem on this install.

I'm not looking for support for third-party packages. What I am trying to offer is a contribution to your 'as simple as possible' instructions.

See also Contributing Bug Reports:

The instructions are correct as written, and are aimed at being as simple as possible for users who may not be familiar with PHP. We can not possibly include instructions for every imaginable installer, see also T4200.

I didn't use the windows-binary installer, I installed php into my cygwin install using the cygwin installer. (It's still on windows, but through another process).

In particular, the install instructions tell you to:

How did you install PHP, exactly?

http://phacility.com can still up a clean test instance in under a minute.

Should note that with the test video I posted, I was able to replicate with a brand new workboard with 5 extra columns (6 total) with zero tasks on them, so the vertical scroll bar has no impact on it.

Tested with:
arcanist: rARCa2ab38df78a9d111459fab8d0d63e74d811edf29
libphutil: rPHU4b44d03ba60c8a67f70a91cb11765b8b61f73598

What version arcanist are you running?

Knowing what the problem is, the workaround is obvious (remove the relevant git config option).

Thanks -- T10778 had instructions which I was more successful with. This should be fixed in HEAD.

@epriestley I updated the description in this ticket.

Oh, thanks. I can reproduce this variant of things. I thought I remembered seeing this...

Do you have a stack trace in your webserver error log? (Often /var/log/apache2/error.log or similar.) I can't immediately reproduce this myself, but that might help narrow down the cause.

I should add that when I am "stuck" in drag mode (no mouse buttons held down, but moving it around scroll me around like I am click-dragging), I can do a fast left-click on an empty spot on the workboard and it becomes unstuck.

Added time markers as it isn't clear what I'm doing with mouse/keyboard without a visual cue.

Thanks for the video, unfortunately I still can't reproduce the issue locally. Everything works for me.

Please see attached .wmv file. I used a technet video capture utility as it was quick and did the job, sorry the quality is not higher but it should do the job.

This the browser I tested:

I can't reproduce the issue you're describing. Maybe make a video to clarify the specific behaviour?

We were able to consistently replicate it on multiple Windows 7 64-bit IE 11.0.9600.17843 (11.0.20) and Windows 7 32-bit IE 11.0.9600.18204 (11.0.28) workstations.

What OS should I be testing?

@epriestley // Oh, I don't know that. Cuz, OS X preview shows repeating animation.
Thanks Very much : )

The GIF data is set to repeat the animation only once (see circled control in footer):

I don't have access to this server. How your server is set up is more important. What php version and what image library are you using? Is it only this gif or other large gifs as well?

@chad // I update the description, but I can't reopen this issue. Should I make a new bug report?

Please fill in all required information for a bug report. Specifically missing are steps to reproduce and what version of Phabricator you are using.

@cspeckmim Sadly I don't have any Mercurial host that is not Phabricator.

@fcoelho oops sorry about the mixup. I've previously had success by downgrading the client to 3.4 or less.

Ok, sorry for the noise, a complete re-install of mysql fixed the issue; I assume that I had not removed all traces of a previous installation as thoroughly as I hoped.

Interesting, thanks. I just followed the "Diffusion User Guide" which states that the git user must have access to the repos as the phd-user.

Here are a few ideas that might shed some light on what's happening:

I can't reproduce this. Here's what I did:

arc diff is supported, but most of these reproduction instructions don't make much sense to me in the context of arc diff -- for example, arc diff does not apply patches.