remove - unstaged changes after reset git




Unstaged changes left after git reset--hard (12)

If other answers are not working, trying adding the files, then resetting

$ git add -A
$ git reset --hard

In my case, this helped when there were a bunch of empty files that git was tracking.

The title says it all.

After git reset --hard, git status gives me files within the Changes not staged for commit: section.

I've also tried git reset ., git checkout -- . and git checkout-index -f -a, to no avail.

So, how can I get rid of those unstaged changes?

This seems to hit only Visual Studio project files. Weird. See this paste: http://pastebin.com/eFZwPn9Z. What is special with those files, is that in .gitattributes I have:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

Also, autocrlf is set to false in my global .gitconfig. Could that be somehow relevant?


If you use Git for Windows, this is likely your issue

I've had the same problem and stash, hard reset, clean or even all of them was still leaving changes behind. What turned out to be the problem was the x file mode that was not set properly by git. This is a "known issue" with git for windows. The local changes show in gitk and git status as old mode 100755 new mode 100644, without any actual file differences.

The fix is to ignore the file mode:

git config core.filemode false

More info here


RESOLVED!!!

I have resolved this problem using following stpes

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/


Another cause for this might be case-insensitive file systems. If you have multiple folders in your repo on the same level whose names only differ by case, you will get hit by this. Browse the source repository using its web interface (e.g. GitHub or VSTS) to make sure.

For more information: https://.com/a/2016426/67824


Check your .gitattributes.

In my case I have *.js text eol=lf in it and git option core.autocrlf was true.

It brings me to the situation when git autoconverts my files line endings and prevent me to fix it and even git reset --hard HEAD didn`t do anything.

I fix it with commenting *.js text eol=lf in my .gitattributes and uncommented it after it.

Looks like it just git magic.


Git won't reset files that aren't on repository. So, you can:

$ git add .
$ git reset --hard

This will stage all changes, which will cause Git to be aware of those files, and then reset them.

If this does not work, you can try to stash and drop your changes:

$ git stash
$ git stash drop

I had the same problem and it was related to the .gitattributes file. However the file type that caused the problem was not specified in the .gitattributes.

I was able to solve the issue by simply running

git rm .gitattributes
git add -A
git reset --hard

I had the same problem. I did git reset --hard HEAD but still every time I did git status I was seeing some files as modified.

My solution was relatively simple. I just closed my IDE (here it was Xcode) and close my command line (here it was terminal on my Mac OS) and tried it again and it worked .

Yet I was never able to find what originated the problem.


In a similar situation. As a result of many years of torment with many programmers who were able to stuff different encodings of the ends of lines (.asp, .js, .css ... not the essence) into one file. Some time ago refused .gitattributes. Settings for repo left autorclf = true andsafecrlf = warn.

The last problem arose when synchronizing from the archive with different ends of lines. After copying from the archive, in the git status many files are changed with the note

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Tips from How to normalize working tree line endings in Git? helped

git add -u


None of these methods worked for me, the only solution was to nuke the whole repo and re-clone it. This includes stashing, resetting, adding then resetting, clrf settings, case sensitivity etc. Sigh..


Run clean command:

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Similar issue, although I'm sure only on surface. Anyway, it may help someone: what I did (FWIW, in SourceTree): stashed the uncommitted file, then did a hard reset.





git-reset