Create symlinks when cloning repos with symlinks

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.2 in an Admin git-bash prompt on Windows 7.

This is expected behavior when core.symlinks is set to false. 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 setting core.symlinks to true in your global .gitconfig.

@dandv

@dandv I am assuming that @elyscape's comment helped you because it is spot on.

Unless 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?

@elyscape

@elyscape: Yes, forgot to include that in the repro steps. Updated the screenshot.

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 --hard

The reset command 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'.

@dscho

I guess that answers our question: Git for Windows does not presently support symlinks at all.

@dscho: Could you reopen this issue? Or should someone make another for the symlink implementation?

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?

Just saw the close. Is this fixed? If so, leaving the issue open has helped :-P

@kblees

Please don't flatter yourself here: @kblees has done all the work. He deserves all of the credit, too.

@dscho

@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

@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

@dscho

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

@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 😜

Noted defaul assignment and elevatation requirements for SeCreateSymb…

Corrected statement about remote symlinks; see git-for-windows/git#11…

Thanks, folks. Are you aware of this git for windows fork supporting symbolic links?
https://github.com/frogonwheels/git/commits/mrg/unicode-symlink-v9

Thanks, folks. Are you aware of this git for windows fork supporting symbolic links?
https://github.com/frogonwheels/git/commits/mrg/unicode-symlink-v9

I 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

@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 set core.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! 🎉

@toolness

@toolness thanks for the update. Thus when installing git should we then check use symbolic links to use this feature on new windows versions?

Made library buildable for windows.

Navigation Menu

Repository navigation

Create symlinks when cloning repos with symlinks #117

27 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Create symlinks when cloning repos with symlinks #117

Description

Activity

elyscape commented on Apr 27, 2015

dscho commented on Apr 27, 2015

dandv commented on Apr 27, 2015

elyscape commented on Apr 27, 2015

dandv commented on Apr 27, 2015

elyscape commented on Apr 27, 2015

dandv commented on Apr 27, 2015

elyscape commented on Apr 27, 2015

dandv commented on Apr 27, 2015

elyscape commented on Apr 27, 2015

elyscape commented on Apr 28, 2015

dscho commented on Apr 28, 2015

dandv commented on Apr 28, 2015

27 remaining items

dandv commented on May 24, 2015

dscho commented on May 25, 2015

dandv commented on May 25, 2015

dscho commented on Aug 26, 2015

dandv commented on Aug 26, 2015

dscho commented on Aug 26, 2015

jbuchberger commented on Feb 9, 2017

PhilipOakley commented on Feb 9, 2017

dscho commented on Feb 9, 2017

toolness commented on May 31, 2017

musm commented on Oct 2, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions