I'm using VS Code with Git - it's in portable location C:\_DEV\bin\git and is also added to Windows PATH so it works just fine with no remotes.
I have a OneDrive _GIT folder where I have some of my "remote" repositories, that sync between 2 devices (sometimes, I have it there mainly for backup purposes).
The error appears when I want to commit changes, only way to "fix" this issue is to restart the computer, so I'd like to find a way how to fix it properly. The problem is, it doesn't appear always and not for all repositories, it's pretty random.
I think it's because of sync from/to OneDrive. Is there a command I can run to fix the file descriptor? Or other way to prevent it?
git remote --verbose
git ls-tree -l HEAD -- a:\new\theme\assets\sass\main.scss
git show 97a333c5e7fce816dbb46a5c1235d69e61836726
git show HEAD:theme/assets/sass/main.scss
git add -A -- a:\new\theme\assets\sass\main.scss
fatal: fsync error on 'sha1 file': Bad file descriptor
Thanks to #edward-thomson.
I had same problem on my PC, where i mapped a folder under my homedrive to E:
C:\Users\myuserid\E-Folder\SomeGitProject
by sharing the folder, so i could shortcut it to
E:\SomeGitProject
Solution was to use the full path in CMD or use the shortcut to homedrive from git bash:
~/E-Folder/SomeGitProject
I guess your A: likewise is a share, that you can access with a full path probably also located somewhere under your homedrive.
I am posting late to help others get to the solution faster than I did. The actual culprit was elusive, and I tried everything from re-installing GIT to creating new repositories.
This happened to me in windows and it was due to a change in permissions in a parent folder somewhere.
The solution was to simply disconnect and remap the folder.
I have had this error a lot recently, and the above answers helped, but another thing that also seems to cause it is VS itself running.
Try closing VS, then doing a "Git Bash Here" from Explorer and using the command line only.
Once done you can then reopen VS.
I also have mapped my root webspace as a drive.
This is no problem until files are watched (like with npm run watch).
I faced same issue. I just resolved this issue with the following steps:
1- Close Visual Code
2- Open project on git bash command line
3- Commit the code again
I had the same problem with visual studio 2017. My solution was to close visual studio, then open Visual studio CODE and merge the files there.
Restarting VS Code works. A bit easier than disconnecting and re-mapping the folder (which also works).
I just had the same problem. In my case the problem was low disk space. Hope this helps someone.
Related
I am new to Git and I did something silly.
I forked a repository from GitHub, then cloned it onto my computer using Git Bash. Long story short, I wanted the directory to be on my desktop but for some reason, I used rm -r Desktop and now all of my desktop files are gone.
I then cloned the repo to my Desktop and it's the only thing I have on there. I tried closing Git Bash since I did not commit any changes but my files are still gone and I am unsure of what to do.
How can I recover my Desktop files? I did not commit or push or do anything of that nature so I'd assume the changes are still local. Thanks in advance for the help!
TestDisk is a tool for recovering files which have been deleted.
Install testdisk
nter testisk into the command line, and the utility will start.
Select your partition to search in.
Select quick search or deeper search.
testdisk will output which files have been recovered and then you can decide to recover or not.
A tutorial on testdisk at the following link,
https://www.journaldev.com/36700/how-to-install-testdisk-on-linux-and-recover-deleted-files
I've been using gitbash these past few days and it's working just fine. But a while ago, after install a pdf reader with patch file, when I opened my gitbash it gave me the error which says "Failed to run '/usr/bin/bash': No such file or directory". I don't know what happened and why, but I think the patch file of the application that I installed has something to do with it. My pc antivirus prompted a warning, and I took actions. Then the trouble in the gitbash happened. Please help me, I don't want to reinstall gitbash again coz I also have to install some things.
Had the same issue, searched for it, this is one of the first few results. So if you are looking why you got this message recently: check your antivirus and that the folder and the file actually exist. As previous answers mentioned, reinstall helps bring it back, but antivirus might break it again. So I would check your antivirus GUI and see if you can restore it and add an exception.
Mine was that Avast antivirus classified it as 'IDP.Generic' threat (weirdly only when I would close the shell with ctrl+c or ctrl+d on Windows 10).
to resolve this issue simply reinstall git.
I disabled Avast antivirus software
Then uninstalled and reinstalled git
It worked for me:)
Like jack this was caused by my virus scanner(avast). To resolve I opened the quarantine page restored and added exemption.
Try 'echo $PATH' in CygWin Terminal to get the PATH it must written something like
/usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/TortoiseHg:/home
Depending on the Chroot in you sshd_config it looks for the /bin/bash file
you will have three options
you might have to copy the files into the Chroot mentioned folder and give the permission.
You can update with you Chroot
Or bind mounting would also help
ref
To resolve this issue simply deactivate your antivirus while reinstalling git.
Windows 7 Ultimate
I used to have Git Shell installed. The icon is grey with a cat face. It was either installed by the Git or by GitHub for Windows.
Somehow I've lost it.
I've tried re-installing both Git and GitHub for Windows, but I can't get it back.
If you have GitHub for Windows (installed, it should come with your shortcut.
It is a shortcut to:
C:\Users\Username\AppData\Local\GitHub\GitHub.appref-ms --open-shell
More recent versions of G4W (see answer below) could have it at:
%LOCALAPPDATA%\Apps\2.0\...\...\
C:\Users\Username\AppData\Local\Apps\2.0\GitHub\GitHub.appref-ms --open-shell
If that shell complains about the absence of git, launch "G4W" itself, which will extract git.
See "Where is git.exe located?".
As mentioned below, to restore the shortcut, after having run the first command, execute in the Git shell:
github --reinstall-shortcuts
Try running the following command:
github --reinstall-shortcuts
That repaired the Git Shell shortcut for me, and also put the proper icon back.
I found out that the answer that you specifically wanted involves a combination of the previous answers:
1. Running the Git Shell via the command line (Since you lost the shortcut)
C:\Users\Username\AppData\Local\GitHub\GitHub.appref-ms --open-shell
2. Once youre in the Git Shell run the command in the previous answer
github --reinstall-shortcuts
You'll find the Git Shell with the grey cat icon that originally came with the GitHub setup in the desktop.
Windows 10
Git-2.19.0-64
The Git Shell is installed by default in:
C:\Program Files\Git\git-bash.exe
Try create a shortcut to your desktop, not sure if this answer your question.
The direct link for Git Shell is now:
https://git-scm.com/downloads
I ran into this same issue today, and since this is the first Google result for my query trying to find a solution, I'll post what I sorted here.
It looks like GitHub for Windows installs some or all of itself into %LOCALAPPDATA%\Apps\2.0\...\...\* and this reference was broken on Git Shell .lnk shortcut on the desktop. The GitHub.exe file pointed to did not exist; the entire path was missing.
I viewed properties on the .lnk file (select Properties from context menu or ALT+ENTER on keyboard with .lnk selected) and clicked the Change Icon button. A message box appeared noting that the path to the old icon file was missing and what the bad path was.
I found the "current" path by poking about in the above noted directory and finding GitHub.exe again. The icon is one of three available in GitHub.exe; I expect this is what some of the other answers (like the reinstall-shortcuts suggestion) accomplish.
Hope this helps someone!
(Which seems to be normal for .NET ClickOnce applications; those ... are randomized/obfuscated/generated so they will look like gibberish. My specific working path, as an example, ended up being: C:\Users\anshou\AppData\Local\Apps\2.0\RZ33EP02.2J7\5OMOZAGM.89T\gith..tion_317444273a93ac29_0001.0003_e68db37a99107794 -- note that this path is not truncated, that is the exact path, double period and all.)
xCode is giving me trouble, and i've been unable to help myself so far.
When I commit my project, xCode reports:
The working copy "[projectName]" failed to commit files
svn: Commit failed (details follow);
svn: '/Users/[user dir]/[path to project]/[source dir]/.DS_Store' is not under versioning control.
Funny thing is, I'm not even trying to add or commit the .DS_Store. Anyway, I tried to resolve this error by deleting .DS_Store using finder (very futile, pops up again right after killing it), and the command line (less futile, but still no luck).
Then I followed this advise http://soledadpenades.com/2009/07/02/keeping-ds_store-files-at-bay/ to add .DS_Store to my ignore list, both in the project dir and all subdirectories using
svn propset svn:ignore .DS_Store .
However, I will admit, that I did not know exactly what I was doing there. I've been using SVN for a long time on Windows exclusively with the Tortoise UI, and feel an appropriate amount of shame for not owning sufficient svn command line skills.
After the ignore, the error looks like this:
The Woking copy "[projectName]" has failed to commit files
svn: Commit failed (details fllow):
svn: File or directory '.' is out of date; try updating
svn: resource out of date; try updating
I guess that happens if you follow advise from the internet blindly without a sufficient level of understanding (shame on me).
Performing an update, didn't do anything, all files were up to date.
Because I don't want to make things worse than they are right now, I'd humbly ask for some help from you awesome guys and gals.
Thanks,
Chris
Answer
Forcing a commit from terminal. After that, using source control in xCode worked fine again.
The Mac OS stores additional information in .DS_Store. This is why you can't delete the folder: The OS needs it.
What you need is to tell SVN to ignore the folder. That's what you did.
For some reason, editing svn:ignore has the side effect that the folder gets "out of sync" (whatever that means).
The solution here is to update the folder: svn up . from the terminal. After that, you can commit the new property.
After restarting Xcode, everything should be fine again.
Try to edit the ignore list from inside Xcode next time, it might do the necessary magic for you.
I have a problem with git.
Basically, here is what I have. I access a svn repository through git. Until now, on python files, everything worked fine.
But lately I also added some pyd, dll and lib files on the repository. THe first update went well. But then, these files have been modified and since then I can't update. These files were added from a windows computer with TortoiseSvn on the svn repository.
If I do a git svn rebase on linux, everything works fine.
If I do a git svn rebase on windows with msysgit (and also tortoisegit), I have the following error : fatal: write error: Invalid argument
If I do a git svn rebase on windows with cygwin, I have the following error : didn't find newline after blob at /usr/lib/perl5/vendor_perl/5.10/Git.pm line 916
I tried several stuff (autocrlf true/false, safecrlf true/false), adding .gitattributes file with the following line *.* -crlf -diff -merge and nothing worked.
I'm a little stuck here so any suggestion would be welcome.
Thanks in advance.
Had identical issue with Msysgit v1.7.2.3, the latest version as at 29 Sep 10, and wanted to share my findings here (Google turns up several cases, but no solutions).
Trying to do "git svn rebase" on a repo (that has this has worked on plenty of times in the past) consistently failed with a "fatal: write error: Invalid argument" after a certain number of commits. The sync would then revert to the beginning again.
I believe this is a bug in Msysgit relating to large(ish) binaries and available memory (on a Win XP SP3 system with 4GB RAM and plenty free HD space). The remote system was the DotNetNuke SVN repo on CodePlex (https://dotnetnuke.svn.codeplex.com/svn).
Initially it was choking on a 330KB "CHM" file (~212th commit, r52261). It consistently did so, even after disabling Avast AV, Google Desktop, etc and verifying that there were no other processes with locks on the repo folder. After a reboot (but opening Outlook, Dreamweaver, etc), it then was consistently and repeatedly failing on a ~15.3MB DLL (~416th commit, same revision).
Finally, after another reboot, disabling Avast, Carbonite and Google Desktop and running no other programs, the sync worked first time.
This seems to point firmly to my conclusion that it was an available memory issue, probably linked to the presence of a largish binary and large number of commits in the revision. Note that I also tried "git fsck", "git svn reset xx" and tweaking the "packSizeLimit" / "usedeltabaseoffset" config vars, without success.
I've found that the best policy for using Git on windows is to tell it to not do anything about line endings.
I don't know if that will help you recover your current git repo, but it's worth a shot.
I set:
[core]
autocrlf = false