Awesome. That worked, thanks.

Please see Support Resources for how to get support using Phabricator. This doesn't appear to be a bug report.

Subscribers were removed from projects, so this policy no longer functions.

I can confirm this behavior. Is there any way to fix that ?

Sure, happy to bring those both upstream.

Implementation of what's described above - also seems to provide the expected results in my case, and limits impact to PHPUnit results. If a file is executed at all, it should show up normally; when completely untouched (which tends to show up with phpunit whitelisting, now necessary in the newest versions).

That seems totally reasonable. It seems like a bit of a stretch for PHP code specifically, but sane as a general-purpose answer.

Ah, I missed "In Diffusion". Let me see if I can reproduce there.

Your steps match mine. However, I'm not getting an "Action With No Effect" prompt; instead, the server acts like it's processing, and redisplays the page, but doesn't actually make any changes.

I'm having trouble reproducing this -- I attempted to follow your steps, but didn't experience the issue. Here's what I did:

In T10300#158235, @cburroughs wrote:

This has tripped me up a few times (maybe since arc was made great again?) and I think it happens when you do arc land foo instead of arc land in foo.

I guess "off" is default, so "disabled" isn't quite accurate.

I think I got 'em all, but let me know if you catch any more.

Thanks :)

This seems to be happening consistently for all new commits.

I can't make a workboard either for the subproject. When I click "Create Workboard" it doesn't do anything

I'm having difficulty reproducing this. Here's what I did:

Generally, multiple JS issues point towards an issue outside of Phabricator (proxy, cache, update procedures).

Nothing here reproduces for me. Are you able to reproduce this issue on a known good installation of Phabricator? Either here or on http://phacility.com?

In T10427#161230, @rbalik wrote:

Also interesting:

From the DB: P has viewPolicy: P, editPolicy: admin, joinPolicy: admin.

What are the view, edit and join policies of the parent project set to?

I just encountered the same error message.

Oh ok, so I guess that doesn't matter then

Note that being an administrator doesn't matter: administrators have no special privileges, and can not bypass policies. See:

Also interesting:

Hmm, that looks like the same process.

Thanks, your reproduction instructions are clear and complete. I was able to reproduce this by following your instructions and narrow it down to a root cause. This should be fixed shortly.

Thanks! This will be in next weeks stable release?

I'm having trouble reproducing this. I tried to follow the instructions you provided to recreate the issue, but didn't seem to experience it. Here's what I did.

Yeah, running a version from Friday: 5eecff91cdd3

Hi! Can you please let us know what version of Phabricator you're running?

@epriestley, test files in last comment indicate 31 can decompress gzip properly.
please check it.

Should be resolved at HEAD. Thanks!

Reading the code around /usr/lib/python2.7/dist-packages/mercurial/sshserver.py:32:

def getargs(self, args):
    data = {}
    keys = args.split()
    for n in xrange(len(keys)):
        argline = self.fin.readline()[:-1]
        arg, l = argline.split()
        if arg not in keys:
            raise util.Abort("unexpected parameter %r" % arg)
        if arg == '*':
            star = {}
            for k in xrange(int(l)):
                argline = self.fin.readline()[:-1]
                arg, l = argline.split()
                val = self.fin.read(int(l))
                star[arg] = val
            data['*'] = star
        else:
            val = self.fin.read(int(l))
            data[arg] = val
    return [data[k] for k in keys]

Thanks for the heads up. I will contact my user with this information. What you said make totally sense to me :).

Thanks, that's helpful.

Sorry I totally forget the version:
phabricator

023cfbb23af36b7f15be86a1f5950b62d68b246d (Mon, Feb 22)

arcanist

fcc11b3a278199fa15b90692aba65f54fef5d7f7 (Wed, Feb 10)

phutil

f43291e99d36045bc459e5133454c0d8fd8768ea (Jan 21 2016)

Hi! Can you tell me what version of Phabricator you're running?

In the very, very general case, I think it's undesirable to favor "N" over "U" because the reports could be coming from two different engines, only one of which knows how to execute the lines.

thanks! :)

I added you to Community if you want to do the honors. :)

Ah, ok. sorry! This was a local issue. But now I can't close this task...

I can't immediately reproduce this, here's what I get:

I promise I searched first! Thanks for the info

Since only the first connection has an issue, you could also conceivably add a slightly-more-than-one-line patch to make arc land run some no-op remote operation (git remote show origin?) and then immediately kill the subprocess, creating and throwing away the bad connection so the followup doesn't hang.

If you're open to patching one site, you can just comment out the feof($stderr) to retain the bulk of the change (i.e., still wait for stdout).

I can sort of see arguments either way, although I think I'm inclined to names too.

Using SSH master connections has two advantages:

1. Connections are indeed faster. In a minimal case (SSH'ing to an adjacent machine on the same network), it reduces the time for a no-op SSH connection from 0.14s to 0.01s. The utility of this grows as one needs to tunnel SSH connections in order to access a machine; for instance, SSH'ing to our Phabricator instance requires bouncing through a bastion host; using SSH master connections reduces the time to connect from ~0.7s to 0.01s. This is notable since arc may produce mulitiple git commands which attempt to fetch from upstream.
2. Authentication information is preserved. If the connection does two-factor authentication, for instance, the user may be supplied with an authentication prompt when the master is set up. Re-using the master preserves this authenticated session, and reduces the amount of re-authorization that the user must do.

I would go for Space Name personally.

Is sorting by Space ID (instead of Space name) definitely your preferred sort?

See also T1279#42118, T9372, T10031, T8080, T6596

The benefit of enabling ControlPersist is only very slightly faster SSH connections, right?