问题
I'm having an issue with a repository at the moment, and though my Git-fu is usually good, I can't seem to solve this issue.
When I clone this repository, then cd into the repository, git status shows several files as changed. Note: I haven't opened the repository in any editor or anything.
I tried following this guide: http://help.github.com/dealing-with-lineendings/, but this didn't help at all with my issue.
I have tried git checkout -- . many times, but it seems not to do anything.
I'm on a Mac, and there are no submodules in the repository itself.
The filesystem is "Journaled HFS+" filesystem on the Mac and is not case-sensitive. The files are one-line and about 79 KB each (yes, you heard right), so looking at git diff isn't particularly helpful. I have heard about doing git config --global core.trustctime false which might help, which I will try when I get back to the computer with the repository on it.
I changed details of filesystem with facts! And I tried the git config --global core.trustctime false trick which didn't work very well.
回答1:
I had the same problem on the Mac after cloning a repository. It would assume all files had been changed.
After running git config --global core.autocrlf input, it was still marking all files as changed. After looking for a fix I came across .gitattributes file in the home directory which had the following.
* text=auto
I commented it out and any other cloned repositories from now on were working fine.
回答2:
I got it. All the other developers are on Ubuntu (I think) and thus have case-sensitive file systems. I, however, do not (as I'm on a Mac). Indeed, all the files had lowercase twins when I took a look at them using git ls-tree HEAD <path>.
I'll get one of them to sort it out.
回答3:
git config core.fileMode false
solved this problem in my case
https://git-scm.com/docs/git-config
TL;DR;
core.fileMode
If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).
The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.
回答4:
I assume you are using Windows. That GitHub page you linked to has the details backwards. The problem is that CR + LF line endings have been committed to the repository already and because you have core.autocrlf set to either true or input, Git wants to convert the line-endings to LF, so git status shows that every file is changed.
If this is a repository that you only want to access, but have no involvement with, you can run the following command to merely hide the issue without actually solving it.
git config core.autocrlf false
If this is a repository that you will be actively involved in and can commit changes to. You may wish to fix the problem by making a commit that changes all the line endings in the repository to use LF instead of CR + LF and then take steps to prevent it from happening again in the future.
The following is taken directly from the gitattributes man page and should be preformed from a clean working directory.
echo "* text=auto" >>.gitattributes
rm .git/index # Remove the index to force Git to
git reset # re-scan the working directory.
git status # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"
If any files that should not be normalized show up in git status, unset their text attribute before running git add -u.
manual.pdf -text
Conversely, text files that Git does not detect can have normalization enabled manually.
weirdchars.txt text
回答5:
Please run the following commands. That might solve the issue.
# Remove everything from the index.
git rm --cached -r .
# Write both the index and working directory from git's database.
git reset --hard
回答6:
In Visual Studio, if you are using Git, you can auto generate the .gitignore and .gitattributes files. The auto generated .getattributes file has the following line:
* text=auto
This line is near the top of the file. We just needed to comment the line out by adding a # to the front of it. After doing that, things operated as expected.
回答7:
The problem might also arise from differing file permissions, as was my case:
Fresh cloned repository (Windows, Cygwin):
$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
Bare remote repository (Linux):
$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
回答8:
I wanted to add an answer more directed on "Why" this happens, because there is already a good answer on how to fix it.
So, .gitattributes has a * text=auto setting, which causes this issue.
In my case, files on GitHub’s master branch had \r\n endings. I have dialed up the settings on the repository to check-in with \n endings. I don't know what Git checks out though. It is supposed to check out with native endings onto my Linux box (\n), but I guess it checked out the file with \r\n endings. Git complains because it sees the checked out \r\n endings that were in the repository and warns me that it will check in \n settings. Hence files are "to be modified".
That's my understanding for now.
回答9:
I had the same problem. Also with a Mac. Looking at the repository on a Linux machine I noticed that I had two files:
geoip.dat and GeoIP.dat
I removed the deprecated one on the Linux machine and cloned the repository again to the Mac. I was not able to pull, commit, stash or pull from my copy of the repository when there were duplicates.
回答10:
The same issue for me. I could see several images with the same name, like "textField.png" and "textfield.png" in the remote Git repository, but not on my local repository. I was only able to see "textField.png" which was not used in the project's code.
It turns out most of my colleagues are on Ubuntu using ext4 filesystem whereas I'm on a Mac using APFS.
Thanks to Sam Elliott's answer, the solution was quite simple. First I asked a colleague on Ubuntu to delete the redundant file versions with the uppercase, then commit and push on remote.
Then I ran the following:
# Remove everything from the index.
git rm --cached -r .
# Write both the index and working directory from git's database.
git reset --hard
Finally, we decided that every developer should change his Git configuration to prevent this to ever happen again:
# Local Git configuration
git config core.ignorecase = true
or
# Global Git configuration
git config --global core.ignorecase = true
回答11:
I also just had the same problem. In my case I cloned the repository and some files were immediately missing.
This was caused by the path to the file and the filename being too long for Windows. To resolve it, clone the repository as close to the hard disk drive root as possible to reduce the length of the path to the file. For example, clone it to C:\A\GitRepo instead of C:\Users Documents\yyy\Desktop\GitRepo.
回答12:
Edit the file called .git/config:
sudo gedit .git/config
Or:
sudo vim .git/config
Contents
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
[remote "origin"]
url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "productapproval"]
remote = origin
merge = refs/heads/productapproval
Change filemode=true into filemode = false.
回答13:
For new versions of macOS this can be caused by a security feature of the OS.
In the repository I was working on, there was a binary file which had *.app as file type.
It was just some serialised data, but macOS treats all *.app files as an application and as this file was not downloaded by the user, the system deemed it insecure and added the com.apple.quarantine file attribute which makes sure the file can not be executed.
But setting this attribute on the file was also changing the file and it therefore showed up in the Git change set without any way of reverting it.
You can check if you have the same problem by running $ xattr file.app.
The solution is pretty simple, as long as you don't have to work with the file. Just add *.app binary to your .gitattributes.
回答14:
I copied my local repository to another folder and a bunch of modified files showed up. My workaround was: I stashed the modified files and deleted the stash. The repository became clean.
回答15:
I found that Git was treating my files (.psd in this case) as text. Setting it to a binary type in the .gitattributes solved it.
*.psd binary
回答16:
Just in case it helps someone else, there can be another cause for this problem: differing versions of Git. I was using the default installed version of Git on a Ubuntu 18.04 (Bionic Beaver) box and everything was working fine, but when trying to clone the repository using Git on Ubuntu 16.04, some files were showing up as modified.
None of the other answers here fixed my problem, but upgrading the versions of Git to match on both systems did fix the problem.
回答17:
I was trying to do an interactive rebase, but it claimed there were some modified files, so it wouldn't let me do it right now. I tried everything to get back to a clean repository, but nothing worked. None of the other answers helped. But this finally worked...
git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'
Boom! Clean repository. Problem solved. Then I just had to drop the last commit when I did my rebase -i and finally everything was clean again. Bizarre!
来源：https://stackoverflow.com/questions/5009096/files-showing-as-modified-directly-after-a-git-clone