There are two Git commands a developer must use in order to discard all local changes in Git, remove all uncommited changes and revert their Git working tree back to the state it was in when the last commit took place. The commands to discard all local changes in Git are: git reset –hard. git clean -fxd.
Look at git stash to put all of your local changes into a "stash file" and revert to the last commit. At that point, you can apply your stashed changes, or discard them.
In order to undo the last commit and discard all changes in the working directory and index, execute the “git reset” command with the “–hard” option and specify the commit before HEAD (“HEAD~1”).
For all unstaged files in current working directory use: git restore . That together with git switch replaces the overloaded git checkout (see here), and thus removes the argument disambiguation. If a file has both staged and unstaged changes, only the unstaged changes shown in git diff are reverted.
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
Here is my experience, set following variables in .git/config
:
[core]
autocrlf = false
safecrlf = false
eol = crlf
then run $ git checkout HEAD .
, and it works. but $ git checkout -- .
not, strange!
* git version 1.9.3
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. ...
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
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)
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With