Repository navigation
Create symlinks when cloning repos with symlinks #117
Description
Activity
This is expected behavior when
core.symlinksis set tofalse. Windows distributions of Git come with that set globally because symlink creation on Windows requires the user to have administrative privileges and the command to be done from an elevated shell (or for UAC to be disabled). If your user account has administrative privileges and you either always use Git from an elevated shell or have UAC disabled, you can enable true symlink support in Git by settingcore.symlinkstotruein your global.gitconfig.Reacted by cnweibo and Philip OakleyUnless I'm missing a step, symlinks just aren't created when cloning the test repo:
You made sure to run
git config --global core.symlinks true?And you're running Git Bash elevated?
I assume so, since I can create files in C:, which otherwise would be met with a "Permission denied":
Try going into the repository and running these commands:
git config core.symlinks true git rm --cached -r . git reset --hardThe
resetcommand errors like this:error: unable to create symlink subdir/test.txt (Function not implemented) error: unable to create symlink test2 (Function not implemented) fatal: Could not reset index file to revision 'HEAD'.Looks like this is the source of the failure.
Unfortunately, we had to drop the NTFS reparse point-based symlink emulation support when updating to 2.1.0: be148fa (see msysgit#231 for details).
Surely the issue should stay open then?
27 remaining items
Just saw the close. Is this fixed? If so, leaving the issue open has helped :-P
@dscho: never have I insinuated that I deserve any credit; I don't care for credit. I'm an ordinary end-user who just wants symlinks on Windows, and your insisting on closing an unfixed issue perplexed me. This wasn't a "WONTFIX"; it was a "HELP WANTED". Why would anyone want to close it?
Experience shows that "just leaving this issue open" will solve exactly nothing.
You might want to adjust your priors based on this new experience of leaving an issue open and seeing another dev step in with a fix (thanks @kblees!).
Would he have jumped in if the issue was closed? Who knows. But I have not seen any rational argument for closing this issue, while leaving it open did correlate with it receiving a fix. You may choose to learn from this or not. I have made my case and will no longer engage.
I would, however, like to thank you for all your contributions to Git for Windows.
Best regards,
Dan@dandv well, as I am revisiting this issue I am left with a little bad taste in my mouth. You could at least have contributed a wiki page describing the intricacies of symlink support on Windows. And let me clarify one thing for you: with Open Source, nobody is an ordinary end-user, because nobody paid for the software. You certainly did not. The downside of getting things for free is that you are expected to do your share to improve the software. You may help others with their problems, you may write documentation about more obscure functions (as -- you guessed it -- symbolic links), you may pay somebody to improve the code. What really, really does not help is to sit back and wait for others to do your bidding.
Oh well, on top of all the work I put into this, I now also have to write that wiki page. sigh
Hi @dscho, thanks for looking over this issue again. I'm fully onboard with your thoughts on open source.
As you can see from my GitHub activity, I'm a pretty active contributor and help whenever I can, even with mundane things like fixing typos. I also contribute on Wikipedia, Slant and in many other places, according to my skills and knowledge.
I'm mostly a JavaScript dev these days who uses git on Windows, and those skills and knowledge, unfortunately, don't happen to include Windows API internals or anything about symlinks really, let alone obscure functions. I'm afraid I'd create more work instead in reviewing my naive contributions. As an ordinary user, when it comes to this particular project I can and am happy to contribute with acceptance testing, high-quality bug reporting, proofreading and building awareness of robust solutions (such as with 1, 2).
@dandv okay, half of my rant was trying to prod you to have a look at https://github.com/git-for-windows/git/wiki/Symbolic-Links and edit it 😜
Thanks, folks. Are you aware of this git for windows fork supporting symbolic links?
https://github.com/frogonwheels/git/commits/mrg/unicode-symlink-v9Thanks, folks. Are you aware of this git for windows fork supporting symbolic links?
https://github.com/frogonwheels/git/commits/mrg/unicode-symlink-v9I see that the last commits there were 2011, and that they were from Karsten and Michael who has contributed here.
While symlinks, in all their variants, are becoming more common on Windows, I'm not sure if an inclusive solution has been found yet that covers all users.
@jbuchberger we integrated a heavily modified version of what you refer to. Git for Windows does handle symlinks just fine, iff the current user has the privilege to create symlinks, and iff the repository does not say
core.symlinks = false. If you clone a repository, and your account has the privilege to create symlinks, Git for Windows will not setcore.symlinks, i.e. if you don't play games with user or system config, it will automatically work as desired.What does not work is to use junction points as if they were symlinks.
As a quick follow-up for anyone who found this thread via Google like me, I think the awesome maintainers of this project just provided what's needed for symlinks on windows to work without admin privileges.
The recent Windows 10 Creators update which was just rolled out does support the creation of symlinks without admin privileges, but it requires that programs like git opt-in to the new behavior by passing a new flag into one of Windows' API calls. This was just merged in #1188, so symlinks should hopefully be a lot easier to deal with in Windows soon! 🎉
Reacted by dlatikay- added a commit that references this issue
on May 18, 2020
I understand the "symlinks on Windows" problem is non-trivial, and there's been ongoing work to support them. Right now cloning a repo with a file symlink will create a plain text file corresponding to the symlink.
Tested with the portable 64-bit
git version 2.3.6.windows.2in an Admin git-bash prompt on Windows 7.