13

I have a modified file which I want to rever to whatever is in the latest commit but it's "stuck" there always being marked as modified.

$ 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:   index.php
#
no changes added to commit (use "git add" and/or "git commit -a")

I then try:

$git checkout -- index.php

But the output of git status is still the same. I then try:

$git reset --hard master
HEAD is now at 02c9613 test commit message

And the output of git status is STILL the same.

Any ideas on how I can get rid of the supposed changes on that file?

Improve this question
4
  • What sort of modifications are there? Commented Dec 15, 2010 at 0:11
  • 2
    What is the result of git diff. It smells like stackoverflow.com/search?q=[git]+autocrlf. Commented Dec 15, 2010 at 8:47
  • The diff shows mainly end of line changes. Note that I haven't changed this file at all. This came from a new member of the team. I'll take a look at Rudi's link. Commented Dec 15, 2010 at 14:50
  • If the "file" is actually a folder, and the diff says the line changed from Subproject commit hash1 to Subproject commit hash2, it means you have a submodule in your project and you need to update it. In this case, do git submodule foreach git pull. If it now says hash1 changed to hash3, go into the submodule folder (the "file") and do git checkout hash1. There are also other ways to do the submodule update, but this worked for me. Commented Feb 6, 2015 at 20:18

6 Answers 6

Reset to default
3

You might be running into a whitespace issue try git config --global apply.whitespace nowarn for that.

If that doesn't work, I'd say you've run into a bug. Save the local clone for future reference (I hope it's not too big) and create a bug report. Especially the facts that:

  • you haven't modified the file yourself
  • other files don't show this problem

are signs that it might just not be you that made the mistake here. Whether you can reproduce the problem on a clean repo would be interesting information too.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Cloned the repo again and it works fine. Can't seem to reproduce the error in the new repo, though. Unfortunately the code here is not open source so I can't really submit it in a bug report :(
3

You have to remove index.php from the "index." Then can you checkout a different version.

git rm --cached index.php

Should do the trick. See:

http://www.kernel.org/pub/software/scm/git/docs/git-rm.html

Improve this answer

2 Comments

Julian's git status output doesn't show anything as being added to the index.
Mike, when I run the git rm command, git wants me to commit the changes which seems strange since I don't want anything to do with this file; I just want it to be exactly like it shows in github.
1

Have you tried:

$ git checkout master -f -- index.php

or

$ git checkout master -f

?

I can't see why this would work if reset did not, but it's worth a try.

Improve this answer

2 Comments

Gauthier, the first command you mention had no effect. But the second did something very interesting. While it didn't do anything at first, I decided to modify some other file, and git status marked it as modified. After I ran your second suggestion, my modified file went back to its original state while the index.php still remained as modified! I'm very close to cloning the repo from the origin again.
I would suggest running git diff as suggested above.
1

try git ls-files -m | xargs -i git update-index --assume-unchanged "{}"

Improve this answer

1 Comment

Just be careful, you'll have to remove that flag to see changes again using --no-assume-unchanged
0

FWIW, I was able to resolve the issue by removing the .git subdirectories within the directories that were showing modified. Once the .git subdirectories (as the subdirectories were .git projects in and of themselves) were gone, the parent folders no longer showed modified. If the files in question are in the same folder as an unrelated .git folder, that might also have an effect.

Improve this answer

Comments

0

I was stuck in the pretty same mess. I had some files I just couldn't get rid of in git status. After trying to reset or checkout the files in any kind of way, I decided to actually add the problematic files and commit them. Git seemed happy with it. I then went back to the previous commit and the problem was solved, the problematic files had indeed disappeared.

It doesn't explain the bug, but if this solution can solve it that's aleady a good thing.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.