Git: How to revert 2 files that are stubbornly stuck at "Changed but not committed"?

user_343414 0
Viewed 47005

I have a repo that has two files that supposedly I changed locally.

So I'm stuck with this:

$ git status
# On branch master
# 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:   dir1/foo.aspx
#       modified:   dir2/foo.aspx
#
no changes added to commit (use "git add" and/or "git commit -a")

Doing git diff says that the entire file contents have changed, even though from eyeballing it that seems untrue (there seem to be common line ranges that diff seems to be failing to see).

Interestingly I don't remember changing these files locally. This repo is used with one remote repo (private, at GitHub.com, FWIW).

No matter what I've tried, I can't discard these local changes. I have tried all of:

$ git checkout -- .
$ git checkout -f
$ git checkout -- dir1/checkout_receipt.aspx
$ git reset --hard HEAD
$ git stash save --keep-index && git stash drop
$ git checkout-index -a -f

In other words I've tried everything described in How do I discard unstaged changes in Git? plus more. But the 2 files remain stuck as "changed but not committed".

What the heck would cause two files to be stuck like this and seemingly "un-revert-table"??

P.S. In the list above showing commands I'd already tried, I mistakenly wrote git revert when I meant git checkout. I'm sorry and thank you to those of you who answered that I should try checkout. I edited the question to correct it. I definitely did already try checkout.

revert github git
15 Answers

I had the same issue, with the interesting addition that the files were changed on windows, but not when looking at them from WSL. No amount of messing around with line endings, resets etc. was able to change it.

Eventually, I found a solution in this answer. Following is the text for convenince:

I have resolved this problem using following steps

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/

user_76532740

This issue can also be cause because git treats capitalization differences as different files but windows treats them as the same file. If a file name only had it's capitalization changed then every windows user of that repo will end up in this situation.

The solution is to confirm the files contents are correct and then recommit it. We had to merge the two files contents together since they were different. Then pull and there will be a merge conflict which you can resolve by deleting the duplicate file. Recommit the merge resolution and you are back to a stable state.

user_56607610

You also might have had a problem related to directories naming letter cases. Some of your colleagues could have changed the name of the directory from e.g. myHandler to MyHandler. If you later on pushed and pulled some of the files of the original directory you would have had 2 separate directories on the remote repository AND only one on your local machine since on Windows you only can have just one. And you're in trouble.

To check if that is the case, just see if the remote repository has double structure.

To fix this, make a backup copy of the parent directory outside of the repo, then delete the parent directory, push it. Make a pull (here's when the second one marked as deleted should appear on status) and push again. After that, recreate the whole structure from your backup and push the changes again.

user_51896560
user_13285130

My issue was something else. No amount of reset, clean, restore, or other git commands resolved my issue. I also tried deleting the file, reverting, etc., and every time I pulled, it would come right back.

> git status
On branch master
Your branch is behind 'origin/master' by 319 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   bucket/stellarium.json

I fixed it by the following:

Rename / move the file out of the way. (--> Not git mv)

> mv .\bucket\stellarium.json .\bucket\stellarium_DELETEME.json
> git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    bucket/stellarium.json

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        bucket/stellarium_DELETEME.json

Restore the file.

> git restore .\bucket\stellarium.json
> git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        bucket/stellarium_DELETEME.json

Delete the renamed file.

> rm .\bucket\stellarium_DELETEME.json
> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

So... ?

Perhaps the disk's FAT got screwed up? I'm not sure. Still don't know. But, it worked.

user_1397930

Been there, time has always been one of my greatest enemy so decided to go with the easiest solution.

  1. move the 2 local version files elsewhere
  2. Commit and push
  3. copy the files manually to the git server
  4. pull
user_122375520

Short answer: check .gitattibutes for any setting that might affect the files that have problems.

For me there was a setting in .gitattributes forcing eol=crlf for some specific files:

*.bat text eol=crlf That was added to force those files have crlf in Windows.

I had to comment that line:

#*.bat text eol=crlf

I use macOS, the problem showed up whenever I was switching branches. Before commenting this setting I had to do a git rm --cached -r . and a hard reset every time.

user_19798610
Related