0

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?

Alexander Zeitler
  • 8,345
  • 7
  • 54
  • 97

1 Answers1

1

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.

Community
  • 1
  • 1
torek
  • 330,127
  • 43
  • 437
  • 552
  • Thanks, absolutely correct. It has been caused by a build output folder which has not been git ignored. As casing of the source files has changed and the old output has not been deleted, there have been two file versions. – Alexander Zeitler Aug 20 '16 at 23:47
  • BTW which details did you miss in the my question? The repo is private so I couldn't share it's URI. – Alexander Zeitler Aug 20 '16 at 23:52
  • What we'd need to show it is, at the least, a list of the modified files, and of the files in the commit itself—or such a list trimmed down to the two path-names that differ only in case. Of course, by the time you get such a trimmed list, the answer is pretty obvious :-) but it really comes down to an "MCVE": http://stackoverflow.com/help/mcve – torek Aug 21 '16 at 01:13