Skip to content
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

Closed
charlescho opened this issue Apr 13, 2016 · 39 comments
Closed

git status shows all files as modified #184

charlescho opened this issue Apr 13, 2016 · 39 comments

Comments

@charlescho
Copy link

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 run git status, in bash on Ubuntu on Windows, it shows what seems to be all of my files as modified and not staged for commit.

@benhillis
Copy link
Member

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.

@charlescho
Copy link
Author

@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 git reset in bash on ubuntu on windows.

@benhillis
Copy link
Member

I'm speculating :)

I'll try this as well and see what I find.

@denisw
Copy link

denisw commented Apr 14, 2016

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:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

@nestalk
Copy link

nestalk commented Apr 14, 2016

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:

git config --global core.autocrlf true

@mjoppich
Copy link

I also think this might be line endings.

I have the very same problem between the "git bash" (mingw) and cygwin ...

@russalex
Copy link
Contributor

Older thread so wanted to clean up.

Tried git config --global core.autocrlf true and it looked to clean up this issue.

Marking this one as fixes for now. I'll close it out as a cleanup in about a week if no additional comments / discussions.

@asher-dev
Copy link

asher-dev commented Mar 20, 2017

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 core.autocrlf and core.filemode.
That is (for the local repository),
git config core.autocrlf true
git config core.filemode false

If I change either of them back to their original setting, every file in the repository is listed as modified.
On another note, unless you're certain that you will only be cloning repositories on git for Windows, I don't recommend changing the --global setting.

@tdaniely
Copy link

tdaniely commented Jan 16, 2018

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
UbuntuOnWindows version 1604.2017.922.0
Ubuntu release is Ubuntu 16.04.3 LTS

Repository was originally cloned with git-for-windows. where autocrlf is also true globally.
Actual files on disk have CRLF.

@barkofdelight
Copy link

Hi there.

I am experiencing a similar problem, which might be part of your problem.

git ls-files has a --debug flag which sheds some light on the matter.

I make repository with a file and in the ubuntu bash script I issue that command, I get this output:

test1
ctime: 1517447477:356798400
mtime: 1517447477:356798400
dev: 12 ino: 212494
uid: 0 gid: 0
size: 14 flags: 0

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 git status on the Windows side, the numbers change!:

test1
ctime: 1517447474:553598100
mtime: 1517447477:356798400
dev: 0 ino: 0
uid: 0 gid: 0
size: 14 flags: 0

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 git lfs (you can search for it and you'll see it numerous times) which has to do with what happens when a filter is changed (or the list of file types it acts upon gets changed). [Turns out this not specific to git lfs and can happen with any filter.]

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.

@lqueryvg
Copy link

lqueryvg commented Apr 8, 2018

I had this problem too. Sharing my problem and solution...

Environment

  • Windows 7
  • VS Code 1.22.1

Problem

I had created a repo using cygwin git version 2.15.1 (I'm using cygwin because zsh is cool, ok?).
Unfortunately, VS Code was picking up git for windows (git version 2.15.0.windows.1) which was reporting all files as modified.

I tried configuring VS Code to pick up cygwin git instead, but they will not play nicely together (surprise surprise 🙄 ):
microsoft/vscode#7998

For me, all suggestions that this was caused by line endings were a red herring.

Solution

The solution was to modify .git/config in the repo to add the following option:

[core]
        filemode = false

This explanation was : helpful
From now on, I'll configure my cygwin environment to use the same "git for windows" that VS code is using, since VS code is forcing me to go down that route.

Epitaph

Trying to get open source tools to work on Windows has always been a PITA. ~20 years of this nonsense, will it ever end ?

@vSanjo
Copy link

vSanjo commented Oct 17, 2018

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 config --global core.autocrlf false && git config --global core.filemode true

@luigip
Copy link

luigip commented Oct 17, 2018

Git comes with Git Bash, which avoids this problem. It also has handy tab-completion, which you don't get in powershell.

@elharony
Copy link

elharony commented Dec 7, 2018

I've faced this issue today when I opened my Local Repos on Ubuntu and I created with Windows, and the solution above doesn't work for me, but I've fixed it using the following:

  • Remove Cache: git rm --cached -r .
  • Then, reset to git's database: git reset --hard

It solved my problem and the files got disappeared from the Staging!

NOTE 1: You will lose all your changes. Be careful!
NOTE 2: If you want to prevent this from happening later, you can change the value of core.ignorecase git's config to true!

@ArturoEsqCR
Copy link

I've faced this issue today when I opened my Local Repos on Ubuntu and I created with Windows, and the solution above doesn't work for me, but I've fixed it using the following:

  • Remove Cache: git rm --cached -r .
  • Then, reset to git's database: git reset --hard

It solved my problem and the files got disappeared from the Staging!

NOTE: If you want to prevent this from happening later, you can change the value of core.ignorecase git's config to true!

This worked for me, as line endings were the same and core->filemode was set to false. Thanks!

@RGKrish183
Copy link

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:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

your solutions was saved my a day. its really helpful

@b-hayes
Copy link

b-hayes commented Nov 27, 2019

Seems that creating files have different permissions as well depending on what you use
image

one interesting thing to note is that I have to run composer from git bash for the vendor bin files to be executable in a docker container within wsl.

@jmcollin78
Copy link

I've faced this issue today when I opened my Local Repos on Ubuntu and I created with Windows, and the solution above doesn't work for me, but I've fixed it using the following:

  • Remove Cache: git rm --cached -r .
  • Then, reset to git's database: git reset --hard

It solved my problem and the files got disappeared from the Staging!

NOTE: If you want to prevent this from happening later, you can change the value of core.ignorecase git's config to true!

Be very carefull with this trick : you will loose all your changes doing this !!

@b-hayes
Copy link

b-hayes commented Dec 8, 2019

I've faced this issue today when I opened my Local Repos on Ubuntu and I created with Windows, and the solution above doesn't work for me, but I've fixed it using the following:

  • Remove Cache: git rm --cached -r .
  • Then, reset to git's database: git reset --hard

It solved my problem and the files got disappeared from the Staging!
NOTE: If you want to prevent this from happening later, you can change the value of core.ignorecase git's config to true!

This worked for me, as line endings were the same and core->filemode was set to false. Thanks!

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.

@mununki
Copy link

mununki commented Jan 28, 2020

I've been suffering from same issue since I switched to WSL in my home machine. I finally fixed this issue with @lqueryvg solution.

git config core.fileMode false for my local repo. I've already change config in global, but I didn't noticed it has been overrided in local.

@b-hayes
Copy link

b-hayes commented Jan 28, 2020

@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:

#!/usr/bin/env bash
if [ ! -f "$2" ]; then
    echo "Usage:"
    echo "    `basename "$0"` +x|-x path/filename.ext"
    exit -1
fi

git update-index --add --chmod=$@
chmod $@

because in windows/wsl the file might be executable for you by default but won't be for anyone else. on Linux or macOS.

@tranhoangthien1990
Copy link

I faced this issue on Window.
Git version 2.18.x
After change
git config core.filemode false git config core.autocrlf true
It's still not fixed for me.
After that, i tried to upgrade my git version to 2.25 then it fixed.

@valterbarros
Copy link

@denisw worked to me on macOs Catalina 10.15.04. I had that problem after copy a folder and use chmod 777 on that.

git version 2.24.2 (Apple Git-127)

Visual Studio Code:

Version: 1.44.2
Commit: ff915844119ce9485abfe8aa9076ec76b5300ddd
Date: 2020-04-16T17:07:18.473Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.4.0

@clioo
Copy link

clioo commented Jun 1, 2020

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:

git config --global core.autocrlf true

Awesome ! this worked for me

@heryudi
Copy link

heryudi commented Jun 8, 2020

Older thread so wanted to clean up.

Tried git config --global core.autocrlf true and it looked to clean up this issue.

Marking this one as fixes for now. I'll close it out as a cleanup in about a week if no additional comments / discussions.

Works for me as well. Thanks!

@Lolkekzor
Copy link

Fix worked, thanks.

@harindaka
Copy link

If you are trying to trigger the git installation in windows from within WSL, then just use git.exe instead of just git. No additional git configuration needed

@cladmi
Copy link

cladmi commented Jun 24, 2020

If you are trying to trigger the git installation in windows from within WSL, then just use git.exe instead of just git. No additional git configuration needed

I am trying to look at a repository with git lfs files on the windows filesystem from WSL.
With all the configurations said in this page the files are still shown as modified.

Using git.exe for listing diff in wsl does not report the lfs tracked files as modified so helps workaround the issue mentioned by @barkofdelight

@Chiramisu
Copy link

See the official documentation for the correct way to resolve line endings conflicts using the .gitattributes file in Git 2.10+. This is the preferred method over setting core.autocrlf true because it goes into source control and resolves the issue for everyone using the repo whereas the git config method resolves the issue only for you.

Sources:
Get started using Git on Windows Subsystem for Linux / Git line endings | Microsoft Docs
Resolving Git line ending issues in containers (resulting in many modified files) | VS Code
Reference Page: .gitattributes | git-scm.com

@receter
Copy link

receter commented Oct 27, 2020

See the official documentation for the correct way to resolve line endings conflicts using the .gitattributes file in Git 2.10+. This is the preferred method over setting core.autocrlf true because it goes into source control and resolves the issue for everyone using the repo whereas the git config method resolves the issue only for you.

Sources:
Get started using Git on Windows Subsystem for Linux / Git line endings | Microsoft Docs
Resolving Git line ending issues in containers (resulting in many modified files) | VS Code
Reference Page: .gitattributes | git-scm.com

Thanks, this is by far the best solution for the line ending issue.

@kantmichel
Copy link

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.

@cyancity
Copy link

same situation here, problem solved

@Prakash-seh
Copy link

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:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

After surfing internet for 30 min, I'm finally able to get it right all thanks to u Sir

@benfulton
Copy link

@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.

This is what I had to do. git config --global core.fileMode false did nothing, while git config core.fileMode false fixed the issue.

@paddy-r
Copy link

paddy-r commented Dec 20, 2022

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 core.autocrlf and core.filemode. That is (for the local repository), git config core.autocrlf true git config core.filemode false

If I change either of them back to their original setting, every file in the repository is listed as modified. On another note, unless you're certain that you will only be cloning repositories on git for Windows, I don't recommend changing the --global setting.

This did it for me (working in Windows with a repo developed in Linux), and only requires local change to settings.

@paddy-r
Copy link

paddy-r commented Mar 22, 2023

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:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

@denisw The first command fixed it for me, thanks, followed by a git reset. The file permissions had indeed been changed by Windows when I copied and pasted a repository. (Lazy, I know, but wanted to avoid re-cloning!)

@fistvan
Copy link

fistvan commented Dec 5, 2023

If the above config settings don't seem to work, you can always check the full configuration parameter list with
git config --list

@sadmananik
Copy link

In my case, this was happening due to file permissions, so I had to run the following command for that file:

git update-index <file>

@Clumsy-Coder
Copy link

I found that running command git update-index --assume-unchanged $(git ls-files | tr '\n' ' ') helps.

obtained from

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests