Open ghost opened 7 years ago
@me-and any comment? I am also requesting new version:
(I really need to get GitHub notifications working in a more reliable fashion; notifications about things I actually care about like this are far too often getting lost in the noise.)
It looks to me like the problem is Cygwin failing to create native symlinks. If you look at the CYGWIN
environment variable documentation, if creating a symlink using winsymlinks:native
fails, it'll fall back to creating Cygwin default symlinks, whereas if winsymlinks:nativestrict
is set, it will fail to create the symlink entirely, which results in Git's default behaviour in environments without symlinks, i.e. setting core.symlinks
to false
and just recording the symlink destination in the file text.
Interestingly, I get the same behaviour with ln -s
in Cygwin Bash on my current machine unless I'm running with Administrator privileges.
The next question, then, is working out why running ln -s
from an elevated Cygwin Bash shell works, but the equivalent within Git doesn't. Next step there, I think, will be digging through strace
output from a Git command that ought to create a Windows native symlink.
I just ran into this and noticed that if I delete a symlink and then use git checkout -f
to restore it, it does come back as a Windows native symlink unlike the behavior from git clone
.
This issue is causing lots of headaches for me over here.
This is a summary of what I found out about this issue: https://superuser.com/questions/1469330/why-cant-i-clone-a-git-repository-with-submodules-in-cygwin-using-windows-nativ/1469332
Cygwin can easily create Windows native symlinks:
However Cygwin Git seems to have no way to create Windows native symlinks:
creates README as a Shortcut (.lnk) file.
creates README as a Cygwin symlink, not a Windows native symlink.
just creates a plain text file, not even a symlink:
http://cygwin.com/ml/cygwin/2017-03/msg00110.html