Can't seem to discard changes in Git

Viewed 85321

After seeing the following from the command line:

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

I am trying to discard my changes by typing the command:

git checkout -- index.htm

but when I re-run git status, it looks exactly the same. The checkout doesn't seem to be working. Am I doing something wrong? I am using GIT 1.6.1.2 on windows/cygwin.

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm
23 Answers

This has been bothering me for a while, almost every repo I'd check out had changes that I couldn't discard. Long story short, I tried all of the above, nothing worked. This is what I did to get things back to normal (on a Mac):

Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo's local config ./.git/config
git rm --cached -r .
git reset --hard

My problem is kind of similar here and I just found out that git is tracking the changes in file permission. I tried discarding and resetting the branch but files are still there. Run git config --get --local core.filemode, if it is true then you need to set it as false to turn off tracking of file permissions. Running git config --local core.fileMode false should solve it. You can read more here

I had the same problem, nothing from the above comments worked. It turned out, that my filesystem is not case sensitive (osx default, but windows probably behaves the same) and a file was present with both uppercase and lowercase in the same directory, with different content. Since on my computer both names pointed at the same file, git status always showed a modification, no matter what I did. To resolve the problem:

  • I had to remove one of the files from another computer and push it to repo

  • delete the whole local version completely

  • do git clone from scratch

I had .gitattributes with the following content:

* text=auto eol=lf

To overcome the issue, edit .gitattributes to remove this line which relaxes line endings. Then git reset --hard HEAD reverted the files and .gitattributes file.

This is an old question, but was still relevant to me. I did not find my answer until asking around the office, and discovered that the problem was with submodules. When they are updated, and your own repository does not reflect those changes, it shows up as having differences, reseting the head doesn't help. If this is the case, run:

git status update

That should help fix things (in this particular case)

I was working on a libGDX project on Android Studio and I wanted to discard all the changes that I have done, and nothing was working for me, the solution I came up with was to commit all the changes into a new branch

git checkout -b TRASH
git add .
git commit -m "discarded changes"
git checkout master

and then you can delete the TRASH branch if you want.

I had a permissions problem in Windows and had to do icacls containingFolder /reset /t /l /c and then double-click the folder to get my permissions back.

For me this issue came up with a combination of downloading an Git-LFS image that was uploaded via Netlify CMS and served differently by their Netlify Large Media handler.

My solution was to comment out/remove these rows from my ~/.gitconfig so that they look like below, and then checking git status again.

# [filter "lfs"]
#   clean = git-lfs clean %f
#   smudge = git-lfs smudge %f
#   required = true

OR you can probably add a more local filter via a .gitconfig in the repo root and somehow overwrite the filter rules for lfs there.

Hope this helps a fellow out.

Many of these answers solve the problem for one of many issues. Thus, you may have to try a few until you find the one that was the problem. So, I'll add my own experience to the mix.

In my case, the issue was that I had a global ~/.gitattributes file in my ~/.gitconfig. When I finally examined that file, I was able to find the problematic extension and rectify it manually.

Specifically for problematic repo I was dealing with, *.bat needed be -text eol=crlf instead of text eol=crlf.

Got the same issue and I have core.autocrlf=false config.

It turns out the issue I got is that there I added * text eol=lf to .gitattibutes file, and committed it to the repo without converting CRLF to LF in all existing files. So these files are shown as modified even in another fresh clone of the repo. It is a little weird that git status reports the files are modified even they have the same CRLF in both git working directory and stage area. It looks to me that modified implies if the file is added and committed, there will be some non-empty change based on current config.

So I git add all the files and committed them (confirmed that the commit includes the conversion of CRLF->LF), and didn't get the modified files report anymore.

Sometimes in Windows the file is being used by another program so git can't do anything with it. First you have to close Visual Studio or whatever program has the file open for execute or write.

In my case my file extension was .txt, so I added

*.txt       eol=crlf

in .gitattributes file which resolved the issue for me.

I also faced somewhat similar problem and the following steps helped me out:

git commit -am 'temp commit'
git pull origin master
git reset head~1
git reset head --hard

Hope it helps other people as well.

Related