I think this use case is reasonable-enough. There's no technical or product reason that the options need to be combined, use cases for separate options were just flimsy/nonexistent the last time this came up IIRC (I think I have an "I'll separate them if anyone has a reasonable use case" comment buried somewhere).

bummer, didn't know arc branch was git only.

Hi Chad,

T5132#69200

From T9190, this may not actually be specific to the cluster.

Maybe rename the edit page "advanced" or something, and let anyone with "can view" see it?

FWIW The particular commit that was causing trouble eventually (!?!) was processed. Since I could reproduce multiple times times with 4x the RAM this feels spooky. Maybe the memory consumption is non-deterministic? Or somehow very different when running in the daemon instead of the cli?

T8612 is related.

well, I can still see the same error with new tasks.

Ah, I see. I did not find any documentation about it, so I assumed the behavior cannot be changed. Thanks.

Yes sorry it wasn't clear

1. Set Default View/Edit Policy to "Custom Policy"
2. Configure some custom policy and save
3. Refresh/edit page for Diffusion Policy settings
4. The value for Default View/Edit Policy is empty, and selecting "Custom Policy" starts a new blank policy instead of showing what was configured earlier.

Ah ok Custom Policy got it to trigger as blank on the edit screen for me.

What specifically are you setting these to (project, all users, custom?)

With 2 minutes of testing, I can't reproduce anything obvious (I'm also on master, but that not old enough to really matter).

Ach! I hadn't thought to look!

Anything in the error logs?

OK, as @shrinidhirao suggested, the fix only works for new tasks. I canceled all failing tasks and wait to see how new tasks work.

I have the same error with the latest code even after I applied the fix from @shrinidhirao.

You have succeeded where I failed ><

98% sure this is a duplicate. Trying to find.

If having the rest of the code run under en_US.UTF-8 is not a problem or even desirable, then that is quite true. It would have implications for eventual localization, though.

Well, if there is a PHP function setlocale() which reliably returns error codes for non-existing locales, then you could simply do something like this:

if (!setlocale(LC_ALL, "en_US.UTF-8") {
  raise_setup_warning(...);
}

Sure, parsing locale -a would be a possibility. It's also possible to stay in PHP, for example:

• locale -a seems fine. The binary belongs to glibc (libc-bin package on Ubuntu 14.04).
• Editing /etc/locale.gen and then executing locale-gen is the usual way to generate locales. The binary belongs to the locales package on Ubuntu 14.04 and iirc to glibc on Gentoo/Linux.

I think we could pick any available UTF8 locale here safely, as they should only differ in collation rules (I think?) and I don't think we ever rely on VCS commands to sort text. I'd also favor a setup warning if only a small number of user are affected and it's easy to install/generate locales, though.

How do you detect that a locale is missing? Parse locale -a?

Configurability is probably not a good idea -- the comment in the code says that other code parses the output from external tools and expects them to give that output in a fixed manner (particularly in English). This looks like it is hard-coded for a reason.

Alternative: Following patch (for the en_GB.UTF-8 locale).

commit 6d6534ebebe881a85382850c6b9817c9e34571fa
Author: Dennis Schridde <dennis.schridde@uni-heidelberg.de>
Date:   Thu Aug 6 15:00:38 2015 +0200

A solution/workaround for this problem appears to be to generate the en_US.UTF-8 locale on the Phabricator host. Restarting Phabricator does not appear to be necessary for the change to take effect, but already-imported repositories will have to be reparsed with bin/repository reparse --all $repository --message --owners.

The problem is this falls under "hypothetical" in how we manage feature requests.

@avivey, thanks for pointing that out, I was trying via https 'credential helper' but I'll give that a try.

@chad I'll reiterate, Google, Amazon and Microsoft now offer their own cloud based git repositories. So its a fair shout that in future a fair proportion of private repos will be hosted with 1 of those companies.

Looks like AWS does allow SSH connection: http://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-credentials-ssh.html looks like a regular SSH configuration, so it should work.

What specifically is your use case here? Are you actually using these services or just testing random things?

I've also now tested it with Visual Studio Online - https://www.visualstudio.com/en-us/version-control-vs
and that works with normal credentials once you have created a 'Personal Access Token' via their GUI.

First I've even heard of these services, I don't think we'll be much help here.

When requesting approvals from 2 different review boards. 1 review board has approved, while the other has yet to take action. Edited the differential and then removed the review board that was still waiting for approval. Executed a git push origin master.

Wow, now that was quick @shrinidhirao. 🚀
At least for MITK-ProjectTemplate it works like a charm, thank you!

Is this right?

when you install a web-server, it would often create a dedicated user and use that.
The exact configuration is dependant on the web-server software you use.

We have the same problem when importing existing git repositories:

So after deactivating Spaces, users cannot see "Repositories" and "Tasks" again. I have tried logging in another administrator user but it still cannot see all repositories and Tasks..

I am currently evaluating Phabricator for use in our company. The one I have set-up is for evaluation purposes only.
I have created an additional task only so that I could send it as a screenshot here. That's why it only has me on the subscribers and authors filters. But the issue was that I cannot see repositories and Tasks in the "All" filters that I have created.
I cannot remember what I have done in the config that brought to this. I have just restored Phabricator to a previous snapshot.
Thank you for the support though! I appreciate it!

I am missing something in this step: "Adding these commands to sudoers will allow the daemon and webserver users to write to repositories as the daemon user."

Okay so I found where this setting was and have set a password now but I still get the same Initialization Error.

Can you list out the steps specifically to reproduce the issue. I'm also interested in how your default view of Maniphest tasks seems to set to only you. How are you configuring Maniphest and what is the workflow you're looking to have set up?

For what it's worth, I can only recreate this issue if I use Spaces (which T8798 already mentioned). I'm on the latest stable (rP535c1a5f255e0da69ea5fbfb230b699eb5a152b1) with a dummy git repo set to project member visibility, and I tried cloning the dummy repo under the following conditions:

Fair enough. I am still seeing this bug at that point. I don't know if it's been fixed later...

64c877702 is about 3 months out of date (April 29).

Still seeing this issue on a hosted phabrictor instance (hosted by phoreplay, so I don't know if it's up to date). Phabricator version 64c87770266444ff6e4a7156a97c6236c1ff090b, Arcanist Version 46ce8a5a35f9057b30151b5cb99a80642d913d22, libphutil Version 00e1f2da28291027b369f363e82c12f0b70de374. No exceptions generated, just out of date tag information.

Cool. Let us know if you're still having issues.

Thanks, I must have forgotten the 'r' prefix when I tried it.

Same happens when I try to push a branch that exists on a different remote:

$ git push origin upstream/hooks
Counting objects: 202, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (127/127), done.
Writing objects: 100% (195/195), 97.63 KiB | 0 bytes/s, done.
Total 195 (delta 64), reused 194 (delta 64)
remote: [2015-07-23 12:20:15] EXCEPTION: (Exception) Unable to identify the reftype of 'refs/remotes/upstream/hooks'. Rejecting push. at [<phabricator>/src/applications/diffusion/engine/DiffusionCommitHookEngine.php:412]
remote: arcanist(head=stable, ref.master=999eb9376568, ref.stable=d54cb072facd), libphremoteuser(head=master, ref.master=1def4e2d7f07), phabricator(head=stable, ref.master=f0bf7a8e2621, ref.stable=2e82fb07cdc1), phutil(head=stable, ref.master=aa6cd8f7e5e5, ref.stable=83f09f6c5a03), sprint(head=production, ref.master=4912ecf41ef1, ref.production=2846fc28ae19)
remote:   #0 DiffusionCommitHookEngine::findGitRefUpdates() called at [<phabricator>/src/applications/diffusion/engine/DiffusionCommitHookEngine.php:220]
remote:   #1 DiffusionCommitHookEngine::findRefUpdates() called at [<phabricator>/src/applications/diffusion/engine/DiffusionCommitHookEngine.php:124]
remote:   #2 DiffusionCommitHookEngine::execute() called at [<phabricator>/scripts/repository/commit_hook.php:133]
To ssh://phab@phab.../diffusion/PV/paraview.git
 ! [remote rejected] upstream/hooks -> upstream/hooks (pre-receive hook declined)
error: failed to push some refs to 'ssh://phab@phab.../diffusion/PV/paraview.git'

You can use bin/policy unlock <object> to open up the policies on an object. For example, bin/policy unlock rXYZ.