Git: How to revert 2 files that are stubbornly stuck at “Changed but not committed”?

Question

I have a repo that has two files that supposedly I changed locally.

So I\'m stuck with this:

$ git status
# On branch master
# Changed but not update         


        

Answer 1

I had the same issue, with the interesting addition that the files were changed on windows, but not when looking at them from WSL. No amount of messing around with line endings, resets etc. was able to change it.

Eventually, I found a solution in this answer. Following is the text for convenince:

---

I have resolved this problem using following steps

1) Remove every file from Git's index.

git rm --cached -r .

2) Rewrite the Git index to pick up all the new line endings.

git reset --hard

Solution was part of steps described on git site https://help.github.com/articles/dealing-with-line-endings/

Answer 2

git checkout dir1/foo.aspx
git checkout dir2/foo.aspx

Answer 3

For me the issue was not about line endings. It was about changing case in folder name (Reset_password -> Reset_Password). This solution helped me: https://stackoverflow.com/a/34919019/1328513

Answer 4

What are the line endings in the files? I'm betting they're CRLF. If they are, check out this guide: http://help.github.com/line-endings/

In short, you need to make sure git is set to convert the line endings to LF on commit, and then commit those files. Files in the repo should always be LF, files checked out should be the OS's native, assuming you set git correctly.

Answer 5

This issue can also be cause because git treats capitalization differences as different files but windows treats them as the same file. If a file name only had it's capitalization changed then every windows user of that repo will end up in this situation.

The solution is to confirm the files contents are correct and then recommit it. We had to merge the two files contents together since they were different. Then pull and there will be a merge conflict which you can resolve by deleting the duplicate file. Recommit the merge resolution and you are back to a stable state.

Answer 6

You also might have had a problem related to directories naming letter cases. Some of your colleagues could have changed the name of the directory from e.g. myHandler to MyHandler. If you later on pushed and pulled some of the files of the original directory you would have had 2 separate directories on the remote repository AND only one on your local machine since on Windows you only can have just one. And you're in trouble.

To check if that is the case, just see if the remote repository has double structure.

To fix this, make a backup copy of the parent directory outside of the repo, then delete the parent directory, push it. Make a pull (here's when the second one marked as deleted should appear on status) and push again. After that, recreate the whole structure from your backup and push the changes again.