For anyone having the babun/cygwin + arc issue, this is how I got around it:

In T11152#181357, @flashydave wrote:

Regarding the specific fault it would be interesting to know why arc expects to be within a repository (either for the user repo or for arcanist) in the first place just to print out a version string. Surely if php can execute arc script that should be sufficient?

@hach-que I have understood that Windows is not the best OS for development, on the other hand you cannot ignore users that use this OS.
Anyway, what can be done in order to fix that ? what do you want me to do ? please be practical. I don't have any budget from the company right now so paying Phacility is not an option right now. I am very talented developer :)

@oujesky thanks for the git link. I was able to get the arc patch command working in the meanwhile with these changes.

At this time if you want to use Phabricator with Windows development, you pretty much have to be prepared to have some support resources and patches internally because Windows isn't a platform that the upstream frequently uses.

running arc patch locally to test the patches should take you less than a minute.

@eadler We are all appreciate your work. I understand you have your own reasons why not applying those patches. But I also know that we cannot use

svn mv

Which is critical operation for development.
On the other side I don't want to miss a history for a file so I cannot use

svn rm
svn add

For now we don't have a hook on our svn (because it still POC) so we commit and then Audit but it really frustrate our team (5 people).

@eadler - oops, sorry about that then :) I'm still behind what I said though ;)

In T8298#187157, @BYK wrote:

@eadler - I'd like to remind you that there are 3 patches waiting for review right now. They have been ...

I don't work for phacility. I, like you, occasionally contribute code as well as administer at this point 5 different copies of phabricator. Sorry for curt tone above.

I'm not sure if Phacility wants it to be used this way but it may be possible to setup a Fund Initiative for prioritizing this. I would likely be able to secure some funds for this feature.

@eadler - I'd like to remind you that there are 3 patches waiting for review right now. They have been sitting there for a few months. That said we are not paying Phabricator. If the only way to get these patches which are already worked on and in pretty good shape merged in is to pay you or maintain a fork I'm really starting to think about crowdsourcing this on Kickstarter or Indiegogo to collect those few hundred bucks to get already working patches landed or simply create a fork and point people there loudly. I also think I almost qualify for "Rise to prominence" sub-section mentioned in https://secure.phabricator.com/book/phabcontrib/article/contributing_code/#alternatives but of course that also relies on you guys letting me contribute more. Making patches sit for months without any feedback and then making me rebase them multiple times is definitely not a great way to encourage people to "Rise to prominence" if you really value that.

currently phabricator is POC on our team, if the company would like it they would purchase it. currently we don't have any budget for POCs at all.
The only thing I can do right now is look into the code and fix it (contribute code).

In T8298#187116, @davidhodeffi wrote:

can you please raise the severity for this issue ? It is really hard to work like that
when renaming a file 'svn mv'. for now we are just committing the code and using an Audit.

can you please raise the severity for this issue ? It is really hard to work like that
when renaming a file 'svn mv'. for now we are just committing the code and using an Audit.

I just ran into the issue with this error on Windows:
Usage Exception: arc diff` is only supported under git, hg, svn.`

In T11105#179265, @hach-que wrote:

This is solved with D11688, but it needs to be turned on globally (at the moment it's a per call option, which was added so that internally our custom unit test runner wouldn't deadlock).

I saw the issues about windows being generally broken. I sympathize with the team's plight having been there too many times with cygwin and git bash over the years. FWIW I think the best approach is to normalize the path references back to unix format as fast as possible. The approach of mapping driver letters C:\ D:\ to /c and /d etc is reasonable. Beyond that there is the usual handling of spaces and () {} etc to consider where php/bash might get confused.

We're basically having lots of problems with Windows; There are a few reports about arc version just not working on Windows (I'm a little surprised @hach-que doesn't run into this; Can you maybe do a quick phriction page about your Windows setup, as in "this setup works, do this"?).

We have a large user base using various install locations on their PC's. The issue has come about following a recent upgrade from a 2015 version with more than one person affected.
If you look at the code I cant see why you would need write access - it is just processing path strings.
Anyway I have moved the install to your suggested directory but with no change to the fault symptom.

As someone who regularly uses Arcanist on Windows, I can't say I've seen this issue. You should try placing Arcanist in a writable directory, like C:\Tools\Arcanist. Installing it into "Program Files" is probably not ideal, as that's not a writable location.

Well, apparently I chose another base than I intended, making the diff huge indeed. The 16554943 lines were correct, thanks for the pointer there. I think this issue can be closed.

(assume you mean to post this on a different Phabricator)

Click "Try Free" then click "Test Instance" after signup.

$20 to use Phacility?

I'll re-test on our private network w/ latest phab soon, who knows maybe it's fixed.

All I needed to test on my home comp's ie as well was access to a 6 column workboard here, but I felt paying 20$ to use phacility was a little steep to keep the bug open.

Can't find a means to reproduce this locally and haven't seen other reports. Can revisit if either of those change.

Since Windows tends to languish near the bottom of the priority list and I'm fairly confident this patch is fine, I'll accept it upstream if you use it for a couple days and nothing explodes and want to submit it.

I suspect that fix is safe and correct. It would be nice to kick the tires a little more before applying it and maybe try to dream up some test coverage, but it shouldn't have broader implications within the arc ecosystem.

@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

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

Any update on this? Th solution proposed by raman is not working for me :(

Back at work... I have the same php, php-curl, and php-json versions in Cygwin and I am still core dumping (with my questionable-or-worse distribution system I'm not sure what arcanist and libphutil versions). I then updated to arcanist b3e68c9 and libphutil adb8a9c and arc doesn't seg-fault anymore. So, it seems to me that the initial trigger has likely been removed from arcanist but the issue that made it a seg-fault instead of a nice stack trace I suppose is still there in the PHP packages.

This also happens on a normal arc install running on Powershell, except that I can't do any of the git_bash workarounds. I have git harnessed through Github's git shell. I'm synced with the most recent php/arcanist as of 12/30/15.

I have had this issue at work for awhile but I just happened to install fresh Cygwin at home and arcanist is working. I installed:

Also, arc sometimes has issues with non-English locals - see T5554.