for future people: git seems to ignore ~/.curlrc but you can pass a proxy using -chttp.proxy or using the https_proxy variable.

Thanks you for looking into it. I was able to sync svn repositories and view the diff.

Yeah, I was pondering the award/revoke flow. PasteEditConduitAPIMethod is so bare bones as an example, and PhabricatorBadgesEditEngine is so different from other edit engines... I'm just not sure how that will hook into the badges edit API method.

The new *.edit endpoints can both create and edit, so a badges.create method would be redundant.

Is there a reason, other than scope, why we're not implementing a badges.create Conduit API method? Or any of the other ones?

@psawant, thanks for the report and for your help building a reproduction case for us on a Phacility instance. It was extremely helpful in identifying and resolving the root cause of this issue.

Thanks for helping us out @psawant!

A workaround is to give the repository a callsign Edit Repository → Edit Basic Information → Callsign.

This is a bug; see T10721 for followup and discussion.

Thanks, looking at this now.

i have restored the repository at http://ec2-52-49-69-145.eu-west-1.compute.amazonaws.com/svn/devpoets/

I have taken down the public repository for time being.

the test instance is at test-7japztksvma2.phacility.com

What's the Phacility test instance? Do you mind if we look at the error there?

I tried out phacility and still seeing the same error. I am going to try out creating a new SVN repository and import it. Will also be trying out a git repository.

This report does not describe a bug.

The staging area is a Git remote that we'll push to, so it should be a valid target for git push <url> ....

This is intentional, so you can use a task as a template to create other tasks if you have, say, several different "open" statuses. The "Create Subtask" action specifically forces the status to the default open status, but I think the current behavior is correct for bare ?template= which has been entered manually.

@paladox, you've been warned repeatedly about your consistently low-quality interactions with this upstream.

@epriestley Configuring a test project with Phabricator and CircleCI, cannot understand what format should the staging area be in.

@chad @epriestley arcanist works straight of the master branch in cmd on windows for me. But git for windows does not work.

@hach-que thanks for your suggestion, you helped me. I get different directors from different command line so cmd throughs C:\Program Files\Git\cmd\git.ex whereas git for windows throughs /mingw64/bin/git

Closing this off as I don't use dynamically allocated hosts any more (it's too much maintenance of custom patches).

I'm hesitant to provide further discussion on this issue because of conversation above, but never-the-less in case anyone else using Windows stumbles across this issue, then here's the following advice:

In T10717#168288, @chad wrote:

I tried to reproduce everything. I have never personally developed on Windows, so everything was done from scratch.

• Windows 10
• Installed git from https://git-scm.com/download/win (2.8.0)
• Installed PHP from http://windows.php.net/download/ (5.6.20, Non thread safe)
• Installed phabricator, arcanist, libphutil from master/HEAD over ssh
• Add PHP/Arcanist to global paths
• Un-comment libcurl in php.ini
• Install arcanist certificate
• use arc patch to pull down patch (see D15596)
• use arc land to push to master (see 7694a6729f6a)

Or keep the patch locally yourself, that's fine as well.

That is, you are still required to provide a valid bug report (steps to reproduce) against a supported environment so that we may observe the bug and verify any fix.

And you understand any "fix" against a beta/unsupported environment is not valid in the upstream, correct?

Yes. It seems it may not be able to find the git. Since git for windows updated a lot of things so I doint know if that check works now. But also I doint know if your check will find git in the 64-bit folder or 32-bit.

Are you still working on a beta of Windows?

@epriestley and @chad ive done some digging at it seems to be this

I'm also not trying to waste your time.

In T10717#168291, @epriestley wrote:

You did not test the patch. As I noted, the patch runs git fetch --queit instead of git fetch --quiet.

You also ignored the large explanatory comment immediately above the changed code which explains why it uses passthru and the specific problem that passthru solves, with a reference to the original issue.

In T10717#168291, @epriestley wrote:

You did not test the patch. As I noted, the patch runs git fetch --queit instead of git fetch --quiet.

You also ignored the large explanatory comment immediately above the changed code which explains why it uses passthru and the specific problem that passthru solves, with a reference to the original issue.

You did not test the patch. As I noted, the patch runs git fetch --queit instead of git fetch --quiet.

In T10717#168285, @epriestley wrote:

@paladox, your interactions with this upstream have consistently wasted our time and energy.

I warned you about untested patches in D14813. D15597 obviously hasn't been tested either since it misspells --quiet.

You need to read Support Resources, Contributing Bug Reports, and Providing Reproduction Steps very carefully and follow the rules they set out. You need to apply common sense, critical thinking, and basic software engineering skills in interactions with this upstream. If you are unable to do these things, you need to stop interacting with the upstream.

I tried to reproduce everything. I have never personally developed on Windows, so everything was done from scratch.

@paladox, your interactions with this upstream have consistently wasted our time and energy.

@chad it seems to be working now

And doing

Oh ok, I'm not sure why I'm getting it and your not.

We still need to be able to reproduce the bug locally.

@chad or we could use exec for windows and proc_open for everyone else.

@chad yes. But php wouldn't stop working like that because of the windows version unless it would.

Aren't you running a beta of Windows?

Could we add something to bypass proc_open since it seems to be a bug on windows.

Yep it is passthru proc_open(): proc_open(): CreateProcess causing the problem.

@chad ive tested it now on your test differential still same problem, I'm using revision https://github.com/phacility/arcanist/commit/57f6fb59d73994d90cd94143787424ce0fdbf73b so it would have failed with proc_open if I was to use the latest revision.

@chad I will test now.

Can you reproduce against our test repositories here? See rGITTEST

It seems arc land carn't find any revisions I created or wont create any.

@chad how do I get the Arcanist version.

Windows / Git / PHP / Arcanist versions would be a good start.

@chad what details do I give you about my envrioment, because it is setup the same as everyone else.

when I run arc land it doesn't detect the revision so I have to manually select it.

Understood, but we still need the details to be able to see and fix the bug locally. Without knowing how or why your environment is different than ours, we have no means of identifying and verifying a fix.

@chad the installer just installs the files it doesn't do anything else so all the files are from phabricator except from installer.

This is just way too far off the map as far was what we take under "Free Support" and "Bug Report". Specifically:

Use the windows installer https://github.com/paladox/Arcanist-installer-for-windows

@chad ok.

OK, I'll leave it open and wait for reproduction steps. Right now the steps provided aren't reproducing in my local environment. Please take the time to include full steps to reproduce, as if you were setting up a whole new computer to isolate the cause. This is what we'll be doing. Loading a VM with your same version, installing the same PHP scripts, etc, etc.

In T10717#168249, @chad wrote:

Is this what you installed? From the page it looks clear that 7.0.4 is a Developer install, not a Stable/Production Install.

@chad I get it even on php 5.6

We don't support PHP7, see my comments above for related tasks. I'll add this as another example though. Thanks for verifying!

Is this what you installed? From the page it looks clear that 7.0.4 is a Developer install, not a Stable/Production Install.

@chad ok ive installed php 7 64bit from http://windows.php.net/download/ and this is the error I still get

More specifically, we have no other reports on Windows issues with arcanist when installed in a supported environment.

@chad the php is based on the official one. Just modified a bit to run with wamstack. Unless it is not modified.

@chad the php is based on the official one. Just modified a bit to run with wamstack. Unless it is not modified.

We don't have PHP7 verified/supported (see T9888, T9640) and we don't support third party installers. In order to accept this you'll need to: