-
Notifications
You must be signed in to change notification settings - Fork 814
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
git status shows all files as modified #184
Comments
Could you check if your git for windows version and git version inside bash are similar? It's possible that there is an incompatibility between the way the versions keep track of changes. |
@benhillis you might be right about that. In windows I have git version 2.7.2 installed, and in ubuntu on windows, I have version 2.8.1 installed. I guess this is not a big deal since I knew all my repos were up to date and I could do a |
I'm speculating :) I'll try this as well and see what I find. |
This could have something to do with WSL reporting the permissions of all files on the Windows filesystem as being 777. Git then regards all files as changed because their permissions are different. Try changing the Git configuration so that permission changes are ignored:
|
It may be line endings,WSL thinks it is linux so it will use LF as the line endings. You can set git to only use CRLF line endings with:
|
I also think this might be line endings. I have the very same problem between the "git bash" (mingw) and cygwin ... |
Older thread so wanted to clean up. Tried Marking this one as fixes for now. I'll close it out as a cleanup in about a week if no additional comments / discussions. |
Just a follow-up to this, since I had the same issue and this thread helped me: The issue was only fixed when I changed the configuration for both If I change either of them back to their original setting, every file in the repository is listed as |
I came across this today, setting both autocrlf=true & filemode=false both globally and in the repo config doesn't work. git status still shows all files as changed. git version 2.7.4 Repository was originally cloned with git-for-windows. where autocrlf is also true globally. |
Hi there. I am experiencing a similar problem, which might be part of your problem.
I make repository with a file and in the ubuntu bash script I issue that command, I get this output:
I run the same command on the Windows side (also using bash, but not via Ubuntu) and I get the same results. So far so good. But...after running
This is a problem. This means that switching platforms invalidates entries in the index cache. This will trigger a re-stat of the invalid files, which will be slow. (In one of my cases, excruciatingly so.) But I know what you're thinking...an invalid cache should just be slow, not produce incorrect results. Yes I agree, but I still suspect this is part of the problem. History: I was tracking down a similar problem in In that situation, this mattered. I was seeing changes on the platform which had the foreign index file. The files were in fact out-of-date. But on the other platform, this fact was hidden by the index matching, as the direct comparison was being skipped in that case. Hope this helps. Even if not, I hope somebody reading this might know more about this index-entry time difference and identify it as a bug or a limitation. Later. |
I had this problem too. Sharing my problem and solution... Environment
ProblemI had created a repo using cygwin I tried configuring VS Code to pick up cygwin git instead, but they will not play nicely together (surprise surprise 🙄 ): For me, all suggestions that this was caused by line endings were a red herring. SolutionThe solution was to modify
This explanation was : helpful EpitaphTrying to get open source tools to work on Windows has always been a PITA. ~20 years of this nonsense, will it ever end ? |
Just a minor update on an old issue. I work on a *nix box through SSH from my MacOS system. Git is updated through Homebrew and there is a mismatch on that version with the box's. To that end, I discovered that as long as both settings match, you'll find the issue resolves itself. For MacOS users, the following helped (on both the *nix box and my desktop):
|
Git comes with Git Bash, which avoids this problem. It also has handy tab-completion, which you don't get in powershell. |
I've faced this issue today when I opened my
It solved my problem and the files got disappeared from the NOTE 1: You will lose all your changes. Be careful! |
This worked for me, as line endings were the same and core->filemode was set to false. Thanks! |
your solutions was saved my a day. its really helpful |
Be very carefull with this trick : you will loose all your changes doing this !! |
If you code is meant to run on a case sensitive file system in production such as any linux server I strongly advise against ignoring case and just commit the filename case changes instead. |
I've been suffering from same issue since I switched to WSL in my home machine. I finally fixed this issue with @lqueryvg solution.
|
@mattdamon108 yeah, unfortunately, git overrides this setting every time you clone a repo for whatever reason the global setting does nothing unless you remove it locally. Another thing you might also want to consider is that if you are creating shell scripts that need to be executable on real Unix systems you will need to update the exec permission in git index manually. and then commit it. I made a script that makes it a little easier. I call it gmod:
because in windows/wsl the file might be executable for you by default but won't be for anyone else. on Linux or macOS. |
I faced this issue on Window. |
@denisw worked to me on macOs Catalina 10.15.04. I had that problem after copy a folder and use git version 2.24.2 (Apple Git-127) Visual Studio Code: Version: 1.44.2 |
Awesome ! this worked for me |
Works for me as well. Thanks! |
Fix worked, thanks. |
If you are trying to trigger the git installation in windows from within WSL, then just use |
I am trying to look at a repository with Using |
See the official documentation for the correct way to resolve line endings conflicts using the Sources: |
Thanks, this is by far the best solution for the line ending issue. |
For me it had something to do with source control inside VScode. Instead of git add . inside powershell I managed the commit inside of VS code. This actually removed the list of all hundreds of files for me. |
same situation here, problem solved |
After surfing internet for 30 min, I'm finally able to get it right all thanks to u Sir |
This is what I had to do. |
This did it for me (working in Windows with a repo developed in Linux), and only requires local change to settings. |
@denisw The first command fixed it for me, thanks, followed by a |
If the above config settings don't seem to work, you can always check the full configuration parameter list with |
In my case, this was happening due to file permissions, so I had to run the following command for that file:
|
I found that running command obtained from |
I have some repos created in windows. When I run
git status
, it shows all files in the branch as up to date and nothing to commit except for a couple of untracked files. When I rungit status
, in bash on Ubuntu on Windows, it shows what seems to be all of my files as modified and not staged for commit.The text was updated successfully, but these errors were encountered: