Question

I have a very strange git error here that has me totally at a loss. It's not a major blocker, but it's extremely irritating to work around all the time.

I have a working copy of a repository and, in said working copy, every time I switch from one branch to another Git tells me, after the switch has completed, that I have local modifications. A few more details:

  1. This is on Windows
  2. Git status shows the file(s) as changed (every line as changed, see attached screenshot for an example)
  3. Beyond compare shows no differences; file encoding and line endings are the same, both files exact same number of bytes.
  4. The weird thing: I can't reset the changes, whatever they are. Even deleting the file and then resetting the deletion results in a new file that is supposedly changed.

What could be going on here? I thought that it might be something to do with file attributes, but I have no idea how to check this.

Screenshot of phantom git changes


Update: VonC was correct that it was line endings that were the issue. More specifically if you have core.autocrlf set to true but any files in the repository that were previously committed with Windows line endings then you will see this issue. The reason it's impossible to reset the change is the fact that checking out the file modifies it, since Git works out that your working copy of the file is different to how it would look if you were to commit it now. Confusing, I know.

Anyway, I was able to fix the issue by making one huge commit that set all the line endings in the repository to Unix, which luckily turned out not to be as huge a pain as you might think. I followed the instructions in this post: Trying to fix line-endings with git filter-branch, but having no luck, specifically the answer by Russ Egan, which worked best for me.

Was it helpful?

Solution

Simply make sure to type (once), before the next checkout:

git config --global core.autocrlf false

That will avoid the kind of automatic eol (end-of-line) transformation that this setting (set to true by default with msysgit) does.
.gitattributes files are a better place to declare the files you want to have their eol managed.

See "git replacing LF with CRLF" for more on that setting.

OTHER TIPS

As I originally posted in this question...

I had some phantom changed files that were showing as modified, but were actually identical.

Running this command sometimes works:
(Turns off git's "smart" but often unhelpful line-ending conversions)

git config --global core.autocrlf false
git config --local core.autocrlf false

But in another case I found it was due to a .gitattributes file in the root which had some line-ending settings present, which was trying to apply autocrlf for certain files even when it was turned off. That wasn't actually helpful, so I deleted .gitattributes, committed, and the file no longer showed as modified.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top