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?

5
  • have those files been added to the index? Commented Aug 20, 2016 at 15:59
  • I did a git clone followed by git checkout develop. Nothing else. Commented Aug 20, 2016 at 16:00
  • Sorry, that should've been clone. I meant git clone -b develop <uri>. Commented Aug 20, 2016 at 16:14
  • Ends up with the same result Commented Aug 20, 2016 at 16:19
  • What kind of changes do you see? Real edits? Line endings? Commented Aug 20, 2016 at 17:01

1 Answer 1

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.

Sign up to request clarification or add additional context in comments.

3 Comments

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.
BTW which details did you miss in the my question? The repo is private so I couldn't share it's URI.
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": stackoverflow.com/help/mcve

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.