1

My quetsion is probably quite similar to this one: Git status shows files as changed even though contents are the same. Although my issue is, that the files in the working directory are exactly the same. I've already done those checks:

git checkout-index <file> --temp
hexdump <tempfile>
hexdump <file>

Both are exactly the same. I also tried this one from an answer to the question above:

git show HEAD:<file>|md5sum
md5sum <file>

They are also exactly the same hashes.

I also tried to undo the changes in multiple ways:

git reset --hard
git checkout -- <file>
git checkout HEAD <file>

But nothing helped. The file is still shown in the git status output as modified. I even deleted the file and copied it over from another folder, where the same repo was cloned. Still no success.

What's even more confusing: The direcrtory is only used for a deployed system. The repo was cloned just minuntes before, and all the sudden, without even touching that specific file in any way, it showed up as changed. I am therefore no longer able to perform a git pull on this directory, as it is telling me, that I have unstaged changes.

Is there any special trick, I can force Git to see the file as unchanged?

P.S. I am very new to Git, just migrated a week ago from SVN. Even though I worked with Git on some projects before, I don't know all the commands, yet.

Community
  • 1
  • 1
2ndkauboy
  • 9,302
  • 3
  • 31
  • 65
  • I don't know if this will help anyone diagnose the problem, but: what system is hosting the repo (Linux? specific version? Windows? etc) and is there anything unusual about the file system (is it ext3, ext4, Windows NT, etc)? – torek Aug 20 '14 at 11:21
  • It is a Debian 7 web server with an ext4 file system on the rootfs partition. It used the default Git 1.7.x version before and I already tried to fix the issue by updating to Git 1.9.1 through the wheezy backports. But still no luck. Even more confusing: If I copy the whole directory with `cp` and that run a `git status` I get even more changed files, I never touched. The only similarity: They are all CSS files and I have a `.gitattributes` file with this line: `.css eol=lf` in it. But as I haven't checkout out anything when copying the folder, that should have no effect. – 2ndkauboy Aug 20 '14 at 11:33
  • All of that looks innocuous except possibly the attributes. Docs claim this should only affect files going *in* (not *out*) but I've never really played with the cr/lf stuff and don't quite trust the docs :-) – torek Aug 20 '14 at 12:04
  • But there is not even a difference in the line endings, as otherwise the MD5 hash and/or the hexdump would be different. I really have no clue, what it could be. – 2ndkauboy Aug 20 '14 at 12:32
  • My thought here was if the files in the repo have CRLF, and something is doing CRLF->LF translation on the way out, but no LF->CRLF on the way in, every extraction will result in a different file than what's in the repo. But that's not the way the documentation says it works, and git's documentation is usually correct, once you figure out what it really means... :-) – torek Aug 20 '14 at 12:46
  • But I have just cloned the repo and everything was OK. Than without writing any file and not even opening or touching this specific file in any way, it appears as changed. And not even being able to do a `git reset --hard` is something I don't understand. – 2ndkauboy Aug 20 '14 at 12:49
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/59655/discussion-between-torek-and-kau-boy). – torek Aug 20 '14 at 12:50
  • I had this issue, turns out I had a watch process running in another terminal, that kept recreating/modifying the file. – Will Hawker Jul 17 '22 at 14:59

3 Answers3

3

It turns out, that removing the .gitattributes file with the following content caused the issue:

*.css       eol=lf

But it still makes no sense at all, as none of the files have been touched. So the issue is not really solved, but removing the .gitattributes file will at least show the correct status again.

2ndkauboy
  • 9,302
  • 3
  • 31
  • 65
2

I had the same problem. I literally executed

git reset --hard

ten times in a row and it disappeared.

Another option is to stop tracking the file

git update-index --assume-unchanged path/to/file

To start tracking it again.

git update-index --no-assume-unchanged path/to/file

Docs for git update-index --[no-]assume-unchanged

Adrian W
  • 4,563
  • 11
  • 38
  • 52
Robotronx
  • 1,728
  • 2
  • 21
  • 43
0

First, start with the following command:

git reset --hard HEAD

Next, use this command to see a list of differing files. If it shows any files, git thinks that there are changes to those files.

git status

Finally if you want to completely overwrite local changes do the following steps:

git reset --hard HEAD
git clean -xdf
git pull
metacubed
  • 7,031
  • 6
  • 36
  • 65
  • 1
    As I mentioned above, I already tried `git reset --hard`. Even with your commands (inlucding `git clean -xdf`), this specific file is still marked as changed. – 2ndkauboy Aug 20 '14 at 11:12
  • I have the EXACT same problem. It is a like stain you cannot remove. The files refuse to budge, no matter what GIT command I execute. – Christoffer Feb 08 '19 at 13:26