Files that haven't changed are shown in the unadorned list after git stash
I have a repo with changes that I want to program ... so I do. After the splash screen, the number of files is shown as changed, although the only "change" is that all lines are displayed as deleted and then added again. I have NOT made these changes. To clarify, these files were not displayed before they were made as there were no changes to them. Here's the fun part, after some experimentation, I found that I can copy the entire directory, do 'git checkout -.' then "git status" and then the files that appear erroneously disappeared. If I try 'git checkout -.' on the original repo, 'git status' shows that they still exist and none of this will get rid of them. Another thing to note, even after copying the repo,if I first "git status", before "git checkout -.", it keeps erroneously showing files as modified when in fact, they haven't changed.
One more note: I read a lot of posts about line endings etc. This is NOT what is happening here. The files are the same in every way.
source to share
One more note: I read a lot of posts about line endings etc. This is NOT what is happening here. The files are the same in every way.
There is a scenario in which files can be identical up to the last byte , but still be "different" according to git status
. And yes, it usually ends with a line end.
My best guess for what's going on is that you are on a Windows machine, and that somewhere in your file .gitattributes
you have a directive that tells git to do line endings normalizations (via * text=auto
or something similar). If so, then when you check the file, its LFs are converted to CRLF, and when you check in the file, its CRLFs are converted to LF.
If so, what is most likely happening is that there is a CRLF in the repository version of the corresponding files somehow. When you check them, working copies will of course also have these CRLFs. Now here is rub: on execution git status
, git diff
etc. git compares what is in repo / index not to what is actually in your working directory, but what would be committed after normalizing the line since CRLFs are replaced with LFs. In this case, git sees that there is a CRLF in the index / repo, and what you would commit only has LF, and hence there is a difference.
To verify that this is the case, run the following commands:
git hash-object path/to/your/file
git hash-object --no-filter path/to/your/file
git ls-files -s path/to/your/file
The first command will show you the hash of what would have been committed. The second command shows the hash of what is actually in your working directory. The third command shows the hash of what is in the index. If the first and second hashes are different, and the second and third hashes are the same, you are almost certainly in the situation I described.
So the question is, how do you get out of this? One easy way is to just add / commit "changes". This will put LF in a copy of the repository, solving the problem in the future. However, if everyone using the repository is on Windows, there is no need to normalize the strings anyway. You can turn them off by placing them * -text
in your .gitattributes
file (and removing any lines below it that specify the file type for the text). The option I chose when I ran into this problem as I am not a fan of my version control system modifying the contents of my files.
source to share