Cloning remote Git repo on Linux machine to an OS X machine results in files with typechange state

Question

I have a working copy directory and lots of its files are being marked as having "typechange" status. Here is the problem I'm having:

$ rm -rf sample-data/
$ git checkout -- sample-data/
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        typechange: sample-data/stereo-frames/LEFT_stereo-test0000.png
        typechange: sample-data/stereo-frames/LEFT_stereo-test0001.png
        typechange: sample-data/stereo-frames/LEFT_stereo-test0002.png
        typechange: sample-data/stereo-frames/LEFT_stereo-test0003.png
        typechange: sample-data/stereo-frames/LEFT_stereo-test0004.png
        typechange: sample-data/stereo-frames/LEFT_stereo-test0005.png
.... etc.

The files in question should all be symlnks. If I go through one by one and do

git checkout -- sample-data/stereo-frames/LEFT_stereo-test0005.png

for example, that file is fixed. However, there are many more files than I have listed here.

Why do I have to manually do this for each file? What is up? The remote Git repo is on a Linux machine, and I'm trying to clone it on my OS X machine.

possible duplicate of [What does "T" mean in "git status"? (it isn't in the man page)](http://stackoverflow.com/questions/8691199/what-does-t-mean-in-git-status-it-isnt-in-the-man-page) — , Jun 04 '14 at 01:49
See also ['typechange' in the git-status output](http://git.661346.n2.nabble.com/typechange-in-the-git-status-output-tp6170106p6170137.html). — , Jun 04 '14 at 01:49
No, I've seen the "What does 'T' mean" post and I don't see how it pertains. My question is not "what does typechange" mean, but in this case, how did it occur? I added some symlinks on one end, and in another place did a git clone and git behaved very annoyingly by creating files instead of symlinks, then complaining that the files it created are not symlinks. How is this proper behavior I ask? — Rich, Jun 04 '14 at 05:15
You did not explain clearly the steps required to reproduce this problem. [This comment](http://stackoverflow.com/questions/24027471/why-does-git-checkout-result-in-typechange-state#comment37038910_24027471) links to a Git discussion where a user used `cp -r` to copy the Git repo, and it is explained that `cp -r` dereferenced the symlink instead of copying it, thus producing this issue. However, without clearer information from you, I cannot tell if you're experiencing a similar issue. — , Jun 05 '14 at 02:18
See also: [What does git do to files that are a symbolic link?](http://stackoverflow.com/a/954575/456814). — , Jun 05 '14 at 02:28
Mac OS X Darwin. I also just tried a complete git clone freshly, which is a PITA as it's a long history and lots of files, and it did not make the problem go away, so it's something deeper than a local corruption, perhaps. — Rich, Jun 05 '14 at 18:19

score 1 · Accepted Answer · edited Jan 18 '21 at 12:34

As shown in the chat logs between myself and Rich, Rich had a remote Git repo on a Linux machine that contained symlinks like the following (information truncated to highlight the important stuff):

$ ls -l  
lrwxrwxrwx Left_stereo-test0000.png -> left_stereo-test0000.png 
-rw-rw-r-- left_stereo-test0000.png

Notice that the symlink shares the same name as the actual file that it links to, except that it differs in case. On a Linux system this would be fine, because it uses a case-sensitive file system.

However, OS X uses a case-insensitive file system (just like Windows does). My guess is that when Rich cloned the Git repo to his OS X machine, it checked-out either the symlink or the file it referenced, and then checking out the other file overwrote the previous one (or something like that), because as far as OS X is concerned, they're the same file.

As Rich explained, once he renamed the files to avoid case-insensitive name collisions on OS X, the problem was solved.

You said it much more completely than I did. You are exactly correct. I did not realize that chat logs could be shared in that way. I guess stackoverflow doesn't suck as bad as I thought. :-) Cheers — Rich, Jun 06 '14 at 03:23

score 0 · Answer 2 · answered Jun 05 '14 at 18:46

0

@Cupcake solved my problem. The issue was the case-insensitive file system employed on OS X Darwin. Renaming the files to avoid name-insensitive collisions fixed the messages.

answered Jun 05 '14 at 18:46

Rich

926
8
17

Cloning remote Git repo on Linux machine to an OS X machine results in files with typechange state

2 Answers2