I'm building a thing that processes incoming file packages, but I have the rather serious problem that I can't sanitize the incoming data until it's in a position to break the processing, and it breaks it such a way that simply restarting the process doesn't fix it.
My current best solution is to git clean -fdx and git checkout . the project directory the process uses, which works like a charm, except that sometimes git clean asks for user input ("cannot unlink file. Retry?"), which causes a problem for automation.
Is there a way to put Git into a non-interactive mode? I need to do this from inside Ruby on a Windows machine.
For Windows, this is what worked for me (sets the GIT_ASK_YESNO environment variable to false, stopping git from asking yes-no questions):
set GIT_ASK_YESNO=false
Then when I get those same messages as warnings but it continues as if I said no.
So git clean -fdx works for me as expected without blocking.
yes no | git clean -fdx
yes no outputs no forever and piping that into git clean causes every prompt to be answered with no.
This generally is because of other processes keeping an handle to those files which "cannot be unliked" (as mentioned in "Cannot unlink a file in PHP/Windows").
That means your automated job has to make sure that all running processes are stopped/killed first, before updating the working directory.
Disclaimer, I don't know Ruby.
Per the documentation, and short of coding up a way to kill all the services that are still running (which may be the best route, depending on your solution and what you need to clean in order to test it) the best it seems we can hope for with this command is to make a shortlist of the files that always result in a [Y/n] prompt.
So, when I see the following: Unlink of file 'packages/RavenDB.Server.2.5.2851/tools/blahblahblah failed.
I add the following to my command:
git clean -fdx --exclude=/packages/RavenDB.Server.2.5.2851**
And, it seems to work.
Related
I have something like this:
WARNING in C:/Data/.../letsTest.jsx
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Data\...\node_modules\babel-loader\lib\index.js?presets[]=es2015&presets[]=react&presets[]=stage-0&presets[]=stage-2!C:\Data\...\letsTest.jsx
Used by 4 module(s), i. e.
multi C:/Data/Doc/13/13080801/LetsTest/letsTest.jsx
* C:\Data\...\node_modules\babel-loader\lib\index.js?presets[]=es2015&presets[]=react&presets[]=stage-0&presets[]=stage-2!c:\Data\...\letsTest.jsx
Used by 1 module(s), i. e.
C:\Data\...\node_modules\babel-loader\lib\index.js?presets[]=es2015&presets[]=react&presets[]=stage-0&presets[]=stage-2!C:\Data\...\r1HeadLearning.js
What is the issue?
Eventually, I found the answer.
It was a Windows issue. It was necessary to change the absolute path in C:\Data...\r1HeadLearning.js from
c:\Data\...\letsTest.jsx
to
C:\Data\...\letsTest.jsx
Delete the node_modules folder and run npm install
That fixed my problem
I just fixed the same warnings on my system, where I'm coding a Create-React-App on Windows 10. Since the Windows file system is not case sensitive, this did not prevent me from continuing to work, but it was ugly to look at on my terminal output. In investigating, none of the available answers helped me. But in a few days of ruminating on the problem I thought of a possible cause. In the recent past I had used npm a couple of times to install modules instead of my usual yarn. Since the warnings were all pointing to node-modules, I decided that could have been a mistake. So here is what I did:
First I merged my develop branch into my master branch, getting everything into one branch.
Next I deleted the entire node_modules folder.
Then I ran yarn install to load all the package.json modules.
Finally I did a yarn start, and the warnings were gone.
Maybe this will help you.
From Contributing.md in create-react-app:
The scripts in tasks folder and other scripts in package.json will not work in Windows out of the box. However, using Bash on windows makes it easier to use those scripts without any workarounds.
so, the easier way is to just install Bash and npm install there. the steps are:
Install Bash on Ubuntu on Windows
A good step by step guide can be found
here
Install Node.js and yarn
Even if you have node and yarn installed on your windows, it would not
be accessible from the bash shell. You would have to install it again.
Installing via
nvm is
recommended.
Line endings
By default git would use CRLF line endings which would cause the
scripts to fail. You can change it for this repo only by setting
autocrlf to false by running git config core.autocrlf false. You
can also enable it for all your repos by using the --global flag if
you wish to do so.
I'm getting this message when trying to rebase interactively using source tree.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
fatal: Unable to create 'X:/sources/project/.git/index.lock': File
exists.
The problem is that X:/sources/project/.git/index.lock doesn't exist
All the other solutions on SO didn't work for me since they all say to remove this file.
I'm on a Mac and ran into basically the same issue.
When running git rebase -i master, I received an error:
fatal: Unable to create 'path/to/file/.git/index.lock': File exists.
The index.lock file didn't exist in my .git/ directory. But there was an index file (no filetype extension). So I aborted the rebase.
After a ton of searching, I finally decided to just create the file:
touch .git/index.lock
I tried rebasing again, but that didn't fix the issue (this time the file really did exist). So I removed it:
rm .git/index.lock
That did the trick. The rebase had conflicts this time (which was odd since I aborted the rebase previously), but I just addressed each conflict and then let the rebase continue:
git rebase --continue
I hope this helps someone else who ends up in a similar situation.
Use rm -rf X:/sources/project/.git/index.lock to remove the lock and save yourself a headache. Also, the index.lock exists, however, the .git folder is hidden. So, use ls -la X:/sources/project/.git to see the content of a hidden folder.
I had the same issue using Github Desktop. I watched the .git directory and the index.LOCK file would appear and disappear. It never persisted for long, so was not there to delete. I investigated a little as other solutions online did not work for me and found that comparing permissions to folders that I was able to commit they had one difference: the .git folder that gave me the error had full control like the others, but it was inherited from its parent. I went to properties->security->advanced and removed then re-added the permissions without inheriting them from the parent. After that I was able to commit my changes without an error.
OK, this is really strange, but for me, the following worked:
Create the file .git/index.lock from Windows explorer
Delete the file again (from git bash, I don't know if this is important)
Then, the command I was executing (git rebase --continue, in my case) succeeded. I have no idea why this procedure worked, though. This should not make any difference...
I disabled indexing of the .git folder and it helped to me to get rid of the message
#Manza: I came across the same issue. There is no index.lock file existing and still it throws an error related to file existence.
I created a patch of my changes and did a clone again. Now when I do a commit, it works all fine. I know this is not the right direction. But this is the go to when the index.lock doesn't get created and still we get this error.
for ios mac remove rm -rf from this location .git/modules/ios or can manual delete
Step —
1)-Open terminal .
2)-Open project file location.
3)-Rum command - defaults write com.apple.finder AppleShowAllFiles YES.
Now u can see hidden file in Mac OS.
4)-Rum command - cd .git/modules/ios (In my case I am running React code).
5)-Now either open folder and delete index.lock or use “rm” command .
6)-Thats its - now try to commit and push .
I've got an odd problem. Using Octopress on OS X, which uses a Rakefile (ruby) to setup deployment folders and such with a unique Git repository structure.
The problem is this line:
system "git add -A"
...in the Rakefile generates this error:
fatal: Will not add file alias 'blog/{obmitted-dir-name}/index.html' ('blog/{OMITTED-DIR-NAME}/index.html' already exists in index)
Ok, so this sounds like a casing issue and I should issue:
$ git config core.ignorecase false
Nope, still the same error and I've verified it is set to false now. So then I issue:
$ git config --global core.ignorecase false
Still no go.
And now for the odd part... I can manually change directories to my _deploy/ dir and issue the command manually:
_deploy/$ git add -A
No problem!
I've verified this numerous times... The Ruby Rakefile cannot issue git add -A, whereas I can do it manually.
I even stopped the script directly on that step and did it manually.
Does Ruby have a different Git environment it runs from?
Is OSX case insensitive even with setting that git flag? If so, that's my problem and I'll never be able to deploy from OSX (just like I can't deploy from Windows): I have upper and lower case aliases for 404s to redirect.
It turns out the issue is indeed that OSX is case-insensative (I didn't know this!) - which in turn doesn't allow git to perform the aliases of different casing.
That's the same issue I had on Windows and is why I moved to Linux. Looks like I'll have to keep a Linux VM handy to handle updates to my static blog (Octopress/Jekyll) cause I do have traffic on both casing of the urls.
If you are reading this and want to remain on OSX with mixed-case blog posts, the answer would be to create a virtual disk that has case sensitivity, mount it permanently and move your Octopress/Jekyll install to it. See: https://gist.github.com/dixson3/8360571
As mentioned in the other answer: macOS (standard hard drive partition) is case insensitive. That means your local git should be the same too.
So, do not do git config core.ignorecase false as that will mess up the things more. Also, if you rename a folder to uppercase, git doesn't track the change, except if you change the files included. So, it is very easy to miss that.
The solution that worked for me is:
Copy all the folder in your case "blog" to a safe place.
Delete with git rm -rf both folders ({obmitted-dir-name} and {OMITTED-DIR-NAME}).
Add and commit the changes.
Create the blog folder again and paste your content with the folder name you want to keep.
Add and commit the changes.
You will need to do that in all related branches too.
I just used a "git clean" command and managed to delete my Documents, Music, and other directories. Is there a way to undo this and somehow get those files back? I did this via Terminal on Mac. Time Machine isn't setup either.
I'm afraid those files are gone. git clean is not reversible since those files were not tracked by git.
From the comments it looks like you had your home folder as git repo, but with nothing tracked.
Running git clean -f removed any file inside the home folder (included the one in the subdirectories), leaving only empty subdirectories (the -d option is required for removing them too).
I'm sorry to inform you that you definitely wiped out your whole home directory. Next time you run a git clean use the -n options to perform a dry run and check what's going to happen before it's too late.
Unfortunately git clean removes all the untracked files, meaning the files that are deleted are not able to be recovered using git. You might be able to check your trash to see if the files still exist there.
I am trying to run git from the command line on my Windows 7, 64 bit machine. It works fine for the most part. I tried pushing my local changes up to my private repository in the cloud.
The command I am trying to run is git push origin master
I use Cygwin 6.1 and it is causing the following error. Presumably related to the fact that I am running on a 64 bit machine
0 [main] git-remote-http 6168 fork: child -1 - died waiting for longjmp before initialization, retry 10, exit code 0xC0000135, errno 11 error: cannot fork() for send-pack: Resource temporarily unavailable
I followed the suggestions here to update my rebaseall file and reran the rebase command. But it didn't really seem to have helped.
Can anyone else reproduce the problem or have found a solution?
Thanks in advance for the help.
The Cygwin mantra I used is "fork failures are rebase issues". longjmp is not the issue, fork is. Rebase is the only solution unfortunately. In the past I have used custom scripts to build the rebase list. I do this because you may be missing some DLLs, especially if you have hand-built stuff. You can build a list with find and then pass it in to rebaseall with -T. You should also consider trying a different base address other than the default one in rebaseall, look at the -b option. 64-bit machines seem to require larger spacing than 32-bit ones and so the default didn't work well for me.
Also if you change any DLLs on your system at all, you'll need to rebase again.
Note: Even after all this fork can still fail in Cygwin. Virus scanners inject their DLLs which screw things up and Windows address space randomization doesn't help either.
The answer mfisch gave worked wonders for my problem.
A quick google search yielded this result which let me git push again in no time at all. The required packages came with the default cygwin install, so I didn't even have to install anything.
The other alternative is to use the msysgit distribution, which will allows you to make any git command without depending on the cygwin environment.
See also "Difference between msysgit and 'cygwin + git'?".