Git diff shows phantom changes

Adam Glauser Source

When I clone a repository on Windows, I see unstaged changes in Git status without making any working tree changes. git diff shows that some changes have occurred, for example

-tablespace development
-storage(initial 10K next 10K maxextents 999);
+tablespace &tablespace
+storage(initial &initial next &next maxextents 999);

However, if I edit the same file using a text editor, those files are not present.

Cloning the same repository on another (Linux) system, I do not have the same problem. This leads me to believe that there are some hooks or other preprocessing steps configured on my desktop.

I can not find any active hooks in $GIT_DIR/hooks, C:\Program Files\Git\etc, or C:\Program Files\Git\mingw\etc.

Using the --no-textconv switch for git diff has no effect.

git add . results in only 1 of the 37 "changed" files being indexed, the rest still show as unstaged changes.

I'm at my wits' end. Any ideas what might be causing Git to show these phantom differences?

Files requested:

# .gitattributes
*           text=auto
*.txt       text
*.vcproj    text eol=crlf
*.sh        text eol=lf
*.shl       text eol=lf
*.jpg       -text


# .git/config
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true
[remote "origin"]
        url = <repo url>
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

note also, git config -l shows

filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process


answered 6 months ago Schwern #1

It's possible there are some files with the same name but different cases, such as foo and Foo. The typical case-insensitive Windows filesystem would only be able to store one. Git might confuse it with the other.

This is a not uncommon problem for projects which have been traditionally Unix exclusive. OS X users will experience similar problems.

A short term solution is to create a small case-sensitive filesystem. On OS X you can make a case-sensitive disk image. I'm not sure about Windows.

The long term solution is to rename the conflicting files and make it project policy to not use overlapping files. This will make the project friendlier to Windows and OS X contributors.

comments powered by Disqus