2

I have a project in git, which when I symlinks down from git the first time, the symlinks do not work. From all I can see they are properly made symlinks. If I remove the symlinks and recreate them myself, git also sees them as Identical to the ones it has.

Is there a setting in Linux or Git that would prevent symlinks from working if they came form git?

The command used to create the symlinks:

ln -s /absolute/path/to/dest symlink-name

Some additional information

  • Symlinks were originally created on a MacBook, but since git sees my newly created symlinks (on linux) as identical, I doubt this is the issue.
  • When getting the symlinks for the first time, they do not work on linux, but on other Mac machines they do.
  • After fixing the symlinks by deleting and recreating them, git sees them as identical and hench they are not overridden in future pulls.
  • All symlinks are to .phar files.
  • The linux machines are running Ubuntu 16.04 or Centos 7

Using ls -lah lists the symlinks as regular files:

-rw-rw-r--.  1 vagrant vagrant   28 Nov 13 09:01 dep
-rw-rw-r--.  1 vagrant vagrant   28 Nov 13 09:01 drupal
-rw-rw-r--.  1 vagrant vagrant   20 Nov 13 09:01 drush
-rw-rw-r--.  1 vagrant vagrant   32 Nov 13 09:01 drush.complete.sh
-rw-rw-r--.  1 vagrant vagrant   29 Nov 13 09:01 drush.launcher
-rw-rw-r--.  1 vagrant vagrant   24 Nov 13 09:01 drush.php
-rw-rw-r--.  1 vagrant vagrant   33 Nov 13 09:01 php-parse
-rw-rw-r--.  1 vagrant vagrant   26 Nov 13 09:01 phpunit
-rw-rw-r--.  1 vagrant vagrant   22 Nov 13 09:01 psysh

Whereas, if I manually remove and recreate the dep symlink, it shows up correctly. Git still sees this as identical and no changes were made.

lrwxrwxrwx.  1 vagrant vagrant   28 Nov 13 09:33 dep -> ../deployer/deployer/bin/dep

Changing the permissions form -rw-rw-r-- to lrwxrwxrwx on the broken symlinks, does not fix them either.

Any help is greatly appreciated.

Dion S. Jensen
  • 167
  • 2
  • 14
  • What do you mean they "do not work"? How do they fail? What does `ls` show? Do they have any special characters? – Edward Thomson Nov 13 '17 at 09:05
  • @EdwardThomson I've edited the post to include such information, thanks for asking as I hadn't thought about providing that information. – Dion S. Jensen Nov 13 '17 at 09:36
  • Why do you write `\absolute\path`? `\` is not a path separator on Linux. – John Zwinck Nov 13 '17 at 12:40
  • @JohnZwinck was just a path placeholder so I wouldn't need to type in the actual path, though that is negated quite a bit later on in my post, used `\\`` in the examply by mistake, will get fixed. (Actual symlink correctly uses `/`) – Dion S. Jensen Nov 13 '17 at 13:15

1 Answers1

2

One of your configuration files has turned off the core.symlinks setting. To find out where this was set, run:

for location in global system local; do
    git config -l --$location |& grep -q symlinks && echo $location
done

This will output whether it is set in the global, system or local location.

The global location is typically $HOME/.gitconfig, the system location is typically /etc/gitconfig, and the local location is typically .git/config in the current repository.

Remove that line and Git should be able to create symlinks properly.

Edward Thomson
  • 74,857
  • 14
  • 158
  • 187
  • `show-origin` does not seem to be a valid option (using git 1.8.3.1) – Dion S. Jensen Nov 13 '17 at 14:39
  • Right, that's a newer setting. I've updated with some shell that will enumerate the configuration locations. – Edward Thomson Nov 13 '17 at 14:50
  • I had it in my local config, it seems SourceTree automatically sets it to false on windows machines, but on mac the setting is never set. – Dion S. Jensen Nov 14 '17 at 11:10
  • Right - it should be set to `false` on Windows (and only on Windows). This is a setting that's actually detected when you create a repository, and cached in the local repository configuration (so that you don't have to constantly detect the filesystem's capabilties). You cannot share a working directory between two systems because of this (and other) configuration caches. – Edward Thomson Nov 14 '17 at 11:28