MK32
MK32

Reputation: 63

Git claims files have changed when contents are identical

I'm attempting to fast forward my branch by four commits made by someone else. However, Git keeps giving me this error:

error: Your local changes to the following files would be overwritten by merge:
    path/to/file/A
    path/to/file/B
    etc.
Please commit your changes or stash them before you merge.
Aborting

As per How do I ignore an error on 'git pull' about my local changes would be overwritten by merge? I tried git stash push --include-untracked followed by git stash drop, but that just resulted in the same error.

Following the directions in the answer to Git showing identical files as changed, I tried rm .git/index; git reset and this did shorten the list of files that Git showed as changed, but there were still some there. git reset --hard restored the list of "changed" files to its original size.

I've also tried removing .gitattributes (which has a text=auto line in it) but the files are still shown as changed. Their line endings are all LF anyway, so I doubt a line ending setting would affect these.

In a moment of desperation, I tried git rm -r -f ., which deleted everything but the .git directory, but upon trying to pull I still get the error about these files having changes that will be overwritten, even when the files are deleted. Of course when I do git reset; git status I have all of the files restored and the same set of files is shown as being changed.

I could just delete the whole repository and re-clone it, but I'd like to figure out what's going on. What is causing this behavior?

Upvotes: 1

Views: 2266

Answers (2)

MK32
MK32

Reputation: 63

Alright, so after a third user working on the same branch ran into the same problem, I did some more digging and found the solution.

Our repository uses a filter to change leading sets of 4 spaces to tabs. To apply the filter to each user's config, I wrote a Bash script that everyone is supposed to run before beginning work in the repository. This particular user hadn't run the script, so he didn't have the filter in place.

When I reset my local version of the repository, Git applied the filter to the files, which resulted in leading spaces being converted to tabs and Git registering a change in the file. Removing the filter temporarily allowed me to fast forward to the latest version of the branch.

I still don't know why Meld (accessed with git difftool) showed no diffs, but when I manually downloaded the repository from the server and checked those files against the changed files, Meld showed the whitespace changes.

Upvotes: 1

VonC
VonC

Reputation: 1329742

Their line endings are all LF anyway, so I doubt a line ending setting would affect these.

Still, to be sure, check the output of git config core.autocrlf.
Set it to false: git config --global core.autocrlf false.

Then: git add --renormalize -- :/. (since Git 2.16)

Upvotes: 0

Related Questions