Git cannot undo modified files
Asked Answered
G

6

11

I just want to get back to a clean working directory, exactly as it was after my last commit. Git is reporting to me a load of file modifications that I haven't made, so I suspect it's something to do with line endings.

I have tried all the usual suspects to do this:

git reset --hard git commit -- . git stash git clean -fd

No matter what I do, git status always shows the same files as having been modified. What can I do? I have uncommitted changes stashed in another branch so I don't want to just blast away everything, but rather just "roll back" my master branch.

EDIT: Output

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   demo/index.html
#   modified:   demo/js/app.js
#   modified:   demo/js/libs/jquery.1.7.1.js
#   modified:   demo/js/libs/matchMedia.js
#   modified:   demo/js/libs/modernizr.js
#   modified:   demo/js/loadr.js
#   modified:   dist/enquire.js
#   modified:   src/include/intro.js
#
no changes added to commit (use "git add" and/or "git commit -a")

Then I try what is suggested and everything else I could find:

WickyNilliams at Nick MBA in ~/Repositories/enquire on master*
$ git checkout -- .
WickyNilliams at Nick MBA in ~/Repositories/enquire on master*
$ git reset --hard
HEAD is now at d70fee4 added meta tag to test demo on mobile #10
WickyNilliams at Nick MBA in ~/Repositories/enquire on master*
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   demo/index.html
#   modified:   demo/js/app.js
#   modified:   demo/js/libs/jquery.1.7.1.js
#   modified:   demo/js/libs/matchMedia.js
#   modified:   demo/js/libs/modernizr.js
#   modified:   demo/js/loadr.js
#   modified:   dist/enquire.js
#   modified:   src/include/intro.js
#
no changes added to commit (use "git add" and/or "git commit -a")

As you can see, no changes despite the rollback.

So then I followed advice and ran a diff ignoring all space, and as suspected it seems there's no differences when ignoring spaces - so i guess it was line endings! What can I do to fix this? I've set to autocrlf to true to no avail.

Granule answered 9/10, 2012 at 23:39 Comment(5)
Have you tried asking git diff to find out what the modification is?Tattered
yeah i had done that, it's basically saying every line has changed which is why i thought something to do with line endings. Strange though that all my work is done on one OS on one computer so not sure how this may have happenedGranule
Is this happening even before you open the files in a text editor after resetting? I once found that my IDE was "helpfully" changing line endings for me without my asking, due to some crazy Preference I had set months ago...Classless
Can you post the relevant part of the git status output?Flatfooted
If you do not modified your files, check this questionJudas
G
9

If you want to just change a file back to the way it was after the last commit, just do a git checkout [file] to get a particular file. But a git reset --hard should have done that to the whole tree. If you think it's just the line-endings, do a git diff and then a git diff --ignore-all-space. If the first diff shows changes and the second one doesn't, then at least you know you have a line-ending problem, in which case you might want to look at this description of git and line endings.

Goebel answered 10/10, 2012 at 0:59 Comment(1)
Thanks, ignoring space showed no diff in files, therefore must be line-endings. Will follow the github article. Was hoping to avoid a commit specifically for fixing line-endings, but guess I'll have to.Granule
S
4

Try the approach explained in the "Re-normalizing a repo" section of this github article after making sure your EOL settings have sensible values (for your OS and repo policy)

Shari answered 10/10, 2012 at 8:22 Comment(2)
indeed git rm --cached -r . before git reset --hard worked for meRoyall
In between both statements I had to do an git add -A, but this worked on my end aswell.Devote
V
3

Contributing my case: There was a file that had a modified state and I could not reset this file using git reset --hard. None of the above commands helped me, the file just was always in modified state.
What was more interesting is that this issue persisted even after the new clone! But git gave me a hint:

... bla bla bla git clone ....
Resolving deltas: 100% (37818/37818), done.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'a/b/c/Myfile.kt'
  'a/b/c/MyFile.kt'

It's turned out that someone on a case-sensitive file system (linux) had accidentally committed two files with the same name, but in different cases and different content. And when I opened this repo on a case-insensetive file system (macOs, windows), git thought that this is the same file and always showed me it as "modified" from MyFile.kt to Myfile.kt or from Myfile.kt to MyFile.kt.

So, I just removed an irrelevant file and leaved only one.

Vd answered 13/8, 2021 at 8:0 Comment(0)
A
0

If Git thinks your files are modified due to its attempts to auto-normalize line endings (which will be true if git diff shows differences, but git diff --ignore-all-space does not), your best solution may be to turn off line ending modification for your project. This works well if your team all uses the same platform (Windows, Linux, etc.) for a given set of files.

To turn off line ending modification for your project, open or create .gitattributes at the root of your repository. Ensure that the file contains this line:

* -text

If the file existed and has a different setting for *, such as * text=auto, replace it with the above line.

Awl answered 24/8, 2016 at 0:58 Comment(0)
S
0

In my case neither git checkout -- . nor git reset --hard nor git clean -fd . did help regardless of the order - there were still one directory left which was "modified". So I've changed into the particular directory and run git checkout -- . from here. Don't know exactly the underlying reasons for why I had to change the directory first but it has surprisingly helped to get rid of those modifications.

Shovelboard answered 21/6, 2020 at 6:50 Comment(1)
thanks -- this helped. Why do such things always happen to me?Pittel
L
0

This might happens when using submodules, you can try a git submodule update

Landtag answered 28/4, 2022 at 20:15 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.