Arcanist/Phabricator crashes on diff update - diff

I have a problem with Arcanist with the following command
arc diff --nounit --nolint --update D1434 --encoding ISO-8859-1 c5b9c50e55aefa013d5a38354a78e91b64f3b195
This command worked fine a few minutes ago before I installed the software sourceTree.
Now arcanist asks if I want to amend my untracked files (like before) which I answer with no.
the next step usual was that arcanist askt if i want to add sprcific reviers.
now it just writes the worde "Provide" on the bash and whatever I type, I get the following message
bash: line 0: read: `abort:': not a valid identifier
Usage Exception: User aborted the workflow.
I already tried to copy the original arcanist files in the installation folder and made a new installation of git, but it didnt help.
Does anyone know the problem?

the problem was the git config at the following entries
core.autocrlf=input
core.autocrlf=true
core.autocrlf=input
probably sourcetree added the 3rd line. after removing the last "core.autocrlf=input" arcanist ist working again

I met the same problem. Repeating the same action on Linux, I found that arc was to ask:
Provide explanation for skipping lint or press Enter to abort:
but somehow only
Provide
appear on the screen. Don't use --nolint, or type something.

Related

dbt deps fails -> the file because it is being used by another process

I've ran "dbt deps" on Windows in VSCode and it runs successfully.
After I tried again with another package included, but it failed with the following;
"[WinError 32] The process cannot access the file because it is being used by another process: 'dbt_packages\dbtvault-0.7.9'"
I've checked and the folder has some contents marked as "Read-Only", every time I change the folder to be non-read-only it changes back.
Has anyone found a solution for this?
Thanks,
Dan
I was having the same issue using VS Code and tried to identify the process that was using the file/folder and prevent it from being accessed (you can check this article https://thegeekpage.com/how-to-find-out-which-process-is-locking-a-file-or-folder-in-windows-10/). It turns out that it was actually VS Code (code.exe) doing this so as a turn around I closed VS Code and ran dbt deps from within the Git bash app and it worked.

Can I recover a different version of a file on VSCode after clicking the wrong button on "resolve save conflict"?

I opened VSCode and was presented with a notification that there was a conflict between two versions of a file. I followed the prompts and got a side-by-side comparison of two versions. I clicked the button that accepts the newer version, believing that VSCode had correctly inferred which version was newer. It had not, and I lost a significant number of changes to the file. Is there a cached copy of the other version anywhere?
Thank you!
ps - I seem to have failed to actually commit the changes in git as well. Not sure how that happened.
After searching through the VSCode appdata, I concluded that it wasn't likely that there was a copy. I found a copy of the bytecode (.pyc file) and used uncompyle6 to get an approximate copy of the version of the .py file I needed to recover. Was able to manually merge from there.
I was flummoxed by this one too. The answer is that you can restore the old version by hitting undo until before the change was made.

Netbeans php-cs-fixer end up with error "Files that were not fixed due to errors reported during linting after fixing:"

I am using php-cs-fixer for code formatting in Netbeans 8.2. When I try to format one file, it shows the error
Files that were not fixed due to errors reported during linting after fixing:
I searched for the fix in many websites, but couldn't get this fixed. Is there any way to fix this? I tried with both php-cs-fixer 1 and php-cs-fixer 2.
The error message means that PHP CS Fixer loaded some files from drive, apply changes on them, and then realised that files are not valid anymore (invalid PHP syntax) after those changes, thus it decided to not save it. That's one of the safety mechanism of PHP CS Fixer to not break your project.
This means that you have found an issue in PHP CS Fixer itself.
Please, verify you are using newest release, maybe the bug was already fixed!
If not, please consider to expose your configuration file (if any) and content of files you got listed at https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/new !
There is also an option to see what happen in progress.
$ ./vendor/bin/php-cs-fixer fix src/ErrorFile.php -vvv
The --verbose option will show the applied rules. When using the txt format it will also display progress notifications.
NOTE: if there is an error like "errors reported during linting after fixing", you can use this to be even more verbose for debugging purpose
-v: verbose
-vv: very verbose
-vvv: debug

Github failed to sync branch

I'm using W7 64 bi , and just got an error from the github client app. It says:
failed to sync branch. you might need to open a shell and debug the state of this repo.
What do I do now ?
I know this will sound crazy, but try restarting your computer.
This happend to me yesterday; I was getting this error, and upon checking: \AppData\Local\GitHub\TheLog.txt
I found messages like:
AppData\Local\GitHub\PortableGit_ca477551eeb4aea0e4ae9fcd3358bd96720bb5c8\bin\sh.exe:
*** Couldn't reserve space for cygwin's heap, Win32 error 0
The problem comes around to GitHub for Windows updating itself (in particular the cygwin-ized PortableGit) in the background while I was using it. Ultimately, some cygwin dlls from the previous PortableGit dlls were still loaded in memory causing errors when trying to execute the new (updated) PortableGit commands.
Restarting cleared out all the previously loaded cygwin dlls.
You might have a more complex problem than my answer can solve, but -- for anyone else who comes across this question -- some basic solutions can be found in this video. In short, status.github.com, git status, and gitstatus are your friends. See what they tell you and then continue your sleuthing with that new information in mind. You can use these tools using Git Shell that comes with the Github Windows client.
I'll note that my own problem stemmed from trying to sync a file that was too large: I only found this by using the Git Shell, which gave me the error when I tried git sync. I'm currently looking for ways to remove the file in question in previous commits so I can sync my repo appropriately. The guide I am currently following can be found here, and if it seems to be taking me in the right direction (it was actually recommended in the Git Shell error message!)
I had this error before, and I fixed it by reinserting the credentials for my github account. Turns out that github logged me out for some reason

TortoiseSVN unable to remove conflict markers?

I know this may sound silly but it seems that, my version of TortoiseSVN is unable to resolve conflicts even for text files. I've followed the manual to the letter (By selectingEdit Conflicts the resolving the conflict via Winmerge, and then, selecting Resolved), but when I viewed the text file, the conflict markers are still there. Is this the expected result? I may be missing something here, but I was expecting the conflict markers to be removed after I did the steps the the previous statement. I thought it maybe winmerge not properly saving, so i tried to upgrade it, but to no avail. I also tried using Araxis merge but also no luck. I think I'm just missing something here but what?
BTW the ff. are the versions of my programs
TortoiseSVN
TortoiseSVN 1.6.7, Build 18415 - 32 Bit , 2010/01/22 17:55:06
Subversion 1.6.9,
apr 1.3.8
apr-utils 1.3.9
neon 0.29.3
OpenSSL 0.9.8k 25 Mar 2009
zlib 1.2.3
WinMerge
Winmerge Version 2.12.4.0
This the configuration for Winmerge in my TortoiseSVN
[WinmergePath] -e -x -ub -dl %bname -dr %yname %base %mine
Did you try it with TortoiseMerge (the merge program included with TortoiseSVN)? In TortoiseMerge, be sure to save first, then click Resolved inside TortoiseMerge.
I've had this happen with my .cs files. There are times when I have to delete the directory contents and update my side again. Even when it meant that I would have to re-apply some of my changes. Like saving anything you are working on, doing intermittent updates will ensure that you have little work to redo should something fail.