Alexander Zeitler Alexander Zeitler - 2 months ago 5x
Git Question

After git checkout files are shown as modified

After doing a

git clone <RepoUri>
(with nothing shown as modified) followed by
git checkout develop
on a particular repository on OS X (git 2.7.4) after the checkout, some files are shown as modified.

Even a
git reset HEAD --hard
does not unchange them.

git diff
actually shows changes within the files.

Why does this happen even I did not change any files?
How can I unchange these files?


Without seeing the actual repository (or at the very least, its URL from which to fetch a copy) I can only guess. I have, however, seen exactly this problem before, specifically on OSX. You can run into the same issue on Windows. The repository in question is most likely developed and maintained by Linux folks.

Git itself is pathname-case-sensitive (and for file contents, encoding-agnostic, although path names must be UTF-8).1 It does not care if you call your files foo or FOO, or even fOo for instance. Both Windows and MacOS, however, default to case-insensitive2 file names.

What this means in pratice is that if you download a repository that has two directories data/Polish/ (with country-based information) and data/polish/ (with shoe-polish information), all the files in one of these overwrite all the files in the other. Even a single Makefile vs makefile file-pair causes problems. This all works fine on the OSes with case-insensitive file systems, or if you extract the repository in a case-insensitive mount-point on OS X, but fails miserably by default.

Probably you have come across such a repository. In the future, though, to get better answers, please include more details in the original question. (There is an unrelated problem that occurs with line endings especially on Windows systems, but this is less likely to be hitting your system.)

1There are some minor exceptions with respect to content, and Git especially encourages UTF-8 encoding for commit messages. File pathnames must be UTF-8 even if the file on the file system uses UCS-2 (Windows), and where there are alternatives for UTF-8 encoding of path name characters, Git should be configured to match the OS's preference if any. See Git and the Umlaut problem on Mac OS X for more about this.

2More specifically, these are case-preserving on file creation, but case-folding on file lookup. This is difficult to get right and I would not trust the OS to open file stra├če when you ask for file STRASSE, for instance. I prefer my OSes not to attempt to fold case in the first place. Both Windows and OS X have non-case-folding file systems, but because both default to doing case folding, programs wind up accidentally depending on it and it's a bit dangerous to turn off case-folding globally. I've been told that MacOS Photoshop breaks if you do that, for instance.