Git creates directory symlink as a file

Question

Given two normal folders in a repo:

drwx------ dir_a/
drwx------ dir_b/

I convert dir_b to a relative symlink pointing to dir_a (ie rm -rf dir_b and ln -s dir_a dir_b so that now it looks like:

drwx------ dir_a/
lrwxrwxrwx dir_b -> dir_a/

After committing, pushing and pulling on another machine I see dir_b shown as a normal file and not as a folder symlink

$ ls -al
drwx------ dir_a/
-rw------- dir_b

Tried removing dir_b and restoring it with git checkout dir_b but it is still recreated as a file, and not a folder symlink. The file system is ext4 which supports symlinks. In fact, doing a fresh git clone on the same partition does create dir_b as a symlink as expected.

In case it could matter I'll mention that the actual name of dir_b starts with a dot (eg .dir_b ).

git clone works correctly, so I could use it as a workaround, but would like to know what exactly is happening and what's the correct way to restore symlinked folders since apparently git checkout symlinked_folder does not recreate the folder as in the original repo.

Answer 1

The fix in this case was to run:

git config core.symlinks true

(It may be wise to check for other non-default settings, especially if the SD-card repository was created by a different OS.)

As discussed in comments, the key element here was that the repository was originally created on a non-symlink-supporting file system, and then moved (copied manually) to a symlink-supporting file system. The git config documentation , down in the section describing core.symlinks , says:

If false, symbolic links are checked out as small plain files that contain the link text. git-update-index(1) and git-add(1) will not change the recorded type to regular file. Useful on filesystems like FAT that do not support symbolic links.

The default is true, exceptgit-clone(1) or git-init(1) will probe and set core.symlinks false if appropriate when the repository is created.

In general, it's a little bit safer to git clone a repository when moving it across logical or physical drives, since the new clone will probe the new file system's settings. Git is fairly good at autodetecting other changes (eg, the index encodes the work-tree path) and most of these settings are OS-specific rather than file-system-specific. If you cross-boot different OSes (or run them under hypervisors) and share some media between then, though, these additional core.* settings may cause issues. See, eg, core.fileMode and core.protectNTFS .