Can't seem to discard changes in Git

G

25

162

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

Gina answered 15/10, 2009 at 23:34 Comment(3)

Does git checkout HEAD -- index.htm (checking out from last committed state, instead of checking out from the index) works? – Tini 16/10, 2009 at 10:9

git checkout HEAD -- index.htm worked for me! – Giltzow 30/7, 2014 at 18:32

#2016904 – Enface 3/5, 2016 at 9:48

R

109

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

Recourse answered 28/9, 2016 at 9:26 Comment(4)

After trying everything above, this was the only thing that worked for me (on Windows) – Vicarial 30/12, 2016 at 21:35

Thank you! Same as Anders told, this solution is working for me also. I replaced autocrlf with # autocrlf – Cresol 12/9, 2018 at 6:30

The only way make it work on Windows for me so far. Thanks – Pulido 7/10, 2020 at 9:52

On, windows, it messed it up further and had to reclone, I've never faced something like this on linux. – Arietta 4/4 at 12:57

V

48

Here is my experience; set the following variables in the .git/config configuration file:

[core]
    autocrlf = false
    safecrlf = false
    eol = crlf

After which running $ git checkout HEAD . works, but running $ git checkout -- . does not - strange!

* git version 1.9.3

Vacant answered 15/8, 2014 at 5:35 Comment(0)

D

37

What changes does git diff show on the file? On windows, I've seen issues with line-endings causing issues like this. In that case, look at what settings you have for git config core.autocrlf and git config core.safecrlf. There is some documentation for these settings here.

I would say, if you are using git svn for integration with subversion, then do make sure autocrlf is turned off. From what I can tell it is just broken in this configuration and it makes most of the tools think files have been changed, when you have done a checkout to revert any changes.

If you are seeing a problem where you do git checkout, and then git status shows the file is still modified, and git diff shows the file is modified on every line in the file, then this is the problem you are seeing.

core.autocrlf

If true, makes git convert CRLF at the end of lines in text files to LF when reading from the filesystem, and convert in reverse when writing to the filesystem. The variable can be set to input, in which case the conversion happens only while reading from the filesystem but files are written out with LF at the end of lines. Currently, which paths to consider "text" (i.e. be subjected to the autocrlf mechanism) is decided purely based on the contents.

core.safecrlf

If true, makes git check if converting CRLF as controlled by core.autocrlf is reversible. Git will verify if a command modifies a file in the work tree either directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If this is not the case for the current setting of core.autocrlf, git will reject the file. The variable can be set to "warn", in which case git will only warn about an irreversible conversion but continue the operation. ...

Disturbance answered 15/10, 2009 at 23:47 Comment(5)

core.autocrlf=true core.safecrlf has not been set. Should this be set to true for windows? Whats the difference between the two? – Gina 15/10, 2009 at 23:57

I would say, leave them both off IF you are using git svn. I added some more detail. – Disturbance 16/10, 2009 at 0:58

I'm assuming he means rotating it by at least 90 degrees – Apophysis 5/8, 2017 at 21:7

When I set both core.autocrlf and core.safecrlf to true, I was able to discard detected changes in the offending files by running 'git reset --hard HEAD'. – Clorindaclorinde 30/1, 2018 at 16:15

Thanks for suggesting git diff. I was struggling to find what the difference is. It was not line endings and most answers suggested to change line ending format and config. However on running git diff I realized that file mode (permissions) was different. – Bibliogony 28/8, 2021 at 3:41

S

28

I think you need to pass -f

From the man page (man git-checkout, GIT-CHECKOUT(1)):

-f, --force
Proceed even if the index or the working tree differs from HEAD.
This is used to throw away local changes.

For instance, discard changes on the current branch and switch to a different branch:

git checkout -f master

Sanbenito answered 19/10, 2009 at 2:14 Comment(5)

Pass -f to what? Would be nice to make the answer complete – Continuate 24/5, 2016 at 6:27

@Matt my intention was not to checkout a different branch. The answer is from 2009 so I don't really remember but judging by the question, I think I meant to pass -f to checkout -- <filename> as in git checkout -f -- filename – Sanbenito 6/7, 2017 at 1:52

@Sanbenito The three comments you had were asking for clarification, which is why I added the "for instance". The example doesn't preclude other uses of -f – Photochemistry 6/7, 2017 at 15:20

Worked for me. git checkout -f master threw "Already on 'master'" but the changes were gone. – Inland 25/9, 2018 at 2:43

Worked me too. I feel safe with -f than those other proposals above – Accompaniment 8/12, 2020 at 2:22

W

17

It might be line endings, as @1800-information suggests, but another possibility is that the difference (that's preventing your from reverting these files with a checkout command) is one of file mode. This is what happened to me. On my version of git you can discover this by using

git diff index.htm

And it will show you file mode changes. It still won't let you revert them, though, using checkout, even with the -f option. For that use either

git config core.filemode false

or change your git .config in your text editor by adding

[core]

filemode = false

After you do this, you can use

git reset HEAD index.htm

and the file should disappear.

(I got all of this from the answers to How do I make git ignore mode changes (chmod)? and updating-file-permissions-only-in-git)

Whereof answered 13/6, 2012 at 15:42 Comment(2)

Thanks a bunch! None of the other suggestions worked for me to get rid of the file mode changes. – Behlau 5/8, 2020 at 11:9

thank you, this solved my issue on windows – Precedential 22/5, 2023 at 6:48

P

7

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

Parisian answered 28/8, 2020 at 8:10 Comment(2)

In my case, I tried the accepted solution, but that didn't work. When I did a git diff, it was complaining for file permissions. So when I set the core.fileMode false and reran the commands: git rm --cached -r . git reset --hard – Convincing 20/9, 2022 at 19:39

This setting works for me. No idea why git config -- global core.fileMode false doesn't work. – Falcate 14/7, 2023 at 12:15

A

5

Are you on OSX or Windows? If so, the problem probably is having two files of the same name, with different case. eg. index.htm and Index.htm

Windows, and by default OSX, uses a case insensitive file system, which conflicts with the case sensitive git.

Anele answered 2/7, 2014 at 7:42 Comment(1)

I believe this is the problem i'm having, a file named both doCheckout and docheckout, and resetting one just makes the other appear. What is the solution? – Milksop 26/10, 2022 at 16:43

S

4

I had this issue and after trying all of the above, nothing worked.

What worked for me was to delete the directory that the file was in, then did git status and made sure that all the files in that dir are now marked as deleted. After that I simply did git checkout -f and everything was back to normal.

Swabber answered 15/6, 2016 at 18:45 Comment(0)

S

2

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

Subauricular answered 30/9, 2019 at 10:54 Comment(0)

P

1

I ended up doing a git stash followed by a git stash clear to get rid of some. Didn't see any auto cr/lf configurations in .git/ or ~/.git stuff.

Photochemistry answered 20/7, 2017 at 15:36 Comment(1)

love this one, easy and fast. it's just it's clear, not clean – Radiophone 31/1, 2023 at 14:29

A

1

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.

Aril answered 2/6, 2018 at 11:18 Comment(1)

nice work around – Yuma 17/1, 2023 at 23:27

F

1

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.

Ferrocyanide answered 9/6, 2020 at 19:43 Comment(0)

A

1

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.

Adieu answered 15/6, 2020 at 18:55 Comment(1)

That's what saved me. I had to delete the files with "differences" from my working tree. Then comment out the lines according to this answer. Then restore the files. Only then the differences were gone. I uncommented the lines afterwards. – Lacroix 22/1 at 9:4

S

0

I've had a similar issue, where it wouldn't allow me to discard files which either does not exist or has been changed. I use Visual Studio at work, and I found that this happens when switching branches while the app is running.

git checkout and trying to discard did not help. It wouldn't work or it would just tell me that I do not have permission.

Solution that worked:

Go into Safe Mode
Discard files

Restarting is a pain, but this worked faster than trying out 100 things.

Spa answered 14/10, 2015 at 19:26 Comment(0)

M

0

There is a easy solution. If this happens (normally from unexpected windows shutdown or memory dump) and you cannot discard your changes and even switch between branches (Git says you don't have enough permission); in Windows environment show all hidden files and folders from folder options. Go to your GIT directory (should be start with .git) and delete the "index.lock" file. Then Git should let you do whatever you want to do.

Maggie answered 27/12, 2015 at 8:55 Comment(0)

S

0

In my case I could not discard changes related to a directory. e.g. when I ran a git diff I would see this: -Subproject commit fdcccccccccccccccccccccccccccccccccccccc +Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

So I called that directory and ran a git status in there. It was in a HEAD detached state. And then I just ran a git checkout master in there. That set things right for me. But this is not helpful for the exact scenario asked in here.

Supporting answered 18/9, 2017 at 21:16 Comment(0)

G

0

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)

Gunther answered 31/10, 2017 at 20:20 Comment(0)

S

0

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.

Stinkwood answered 8/5, 2019 at 23:58 Comment(0)

P

0

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.

Pascual answered 28/9, 2020 at 16:58 Comment(0)

A

0

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.

Aforetime answered 9/1, 2021 at 3:56 Comment(0)

S

0

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.

Stumpf answered 19/1, 2022 at 17:13 Comment(0)

M

0

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

*.txt       eol=crlf

in .gitattributes file which resolved the issue for me.

Mixedup answered 1/3, 2022 at 7:57 Comment(0)

F

0

I had an issue where even on a completely fresh checkout git status would show changes to files, which were due to LF/CRLF swaps, even though the files where not plaintext files.

To resolve, I marked these files as binary in the .gitattributes file:

<path_to_problematic_files> binary

Fletcherfletcherism answered 19/6, 2023 at 20:45 Comment(0)

P

0

A simple but tricky solution

Do a temporary commit first.

git add <file>
git commit -m "Dummy"

The reset HEAD one step back.

git reset --hard HEAD~1

Polyandrist answered 16/1 at 6:45 Comment(0)

R

-1

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.

Rayleigh answered 5/10, 2017 at 10:56 Comment(0)

Recommended topics

Hot tags