Cloning a repo on Windows breaks symlinks #4107

bquistorff · 2017-02-03T20:07:14Z

I can't clone faithfully repos with symlinks on Windows. I have been able to do this using Git for Windows (info) when in Administrator mode and setting core.symlinks=true.

Reproduction steps

I am using libgit2 through R with the git2r package.
Start R in administrator mode

> git2r::config()
programdata:
        color.branch=auto
        color.diff=auto
        color.interactive=true
        color.status=auto
        core.autocrlf=true
        core.fscache=true
        core.symlinks=true
        diff.astextplain.textconv=astextplain
        help.format=html
        http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
        rebase.autosquash=true
global:
        core.symlinks=true
        filter.lfs.clean=git-lfs clean -- %f
        filter.lfs.process=git-lfs filter-process
        filter.lfs.required=true
        filter.lfs.smudge=git-lfs smudge -- %f
> git2r::clone("git://github.com/imbs-hl/ranger.git", "C:/Users/USER/Documents/GitHub/ranger2", progress = FALSE)
Local:    master C:/Users/USER/Documents/GitHub/ranger2/
Remote:   master @ origin (git://github.com/imbs-hl/ranger.git)
Head:     [47eb75a] 2017-01-20: Merge pull request #157 from imbs-hl/fix_extratrees

Expected behavior

Expect many symlink files in ranger-r-package/ranger/src folder.

Actual behavior

Many text files in ranger-r-package/ranger/src folder where file contents are the original symlink target paths.

Version of libgit2 (release number or SHA1)

git2r version 0.18.0.9000 (latest release) which say that it has libgit2 commit 6b0510e from 20 December 2016

Operating system(s) tested

Windows 10 Enterprise

The text was updated successfully, but these errors were encountered:

ethomson · 2017-02-08T10:27:37Z

I truly dislike the core.symlinks option, but I suppose it's something that we should indeed support. (To be honest, though, this isn't really on my radar at the moment.)

csware · 2017-03-20T11:42:19Z

I just want to add that symlinks on Windows require a local Administrator and administrative privileges (elevated mode by default, but the right to create sylinks can also be granted to "normal" users, at least with Win10; https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/).

Please also see https://github.com/git-for-windows/git/wiki/Symbolic-Links on how Git for Windows handles symlinks.

jabbera · 2017-06-14T14:52:51Z

@csware the admin requirement is no longer needed for windows 10 creators.

cyberbit · 2017-06-29T15:39:37Z

@jabbera But only if the user has Developer Mode enabled.

Closes #90. Closes #83. Closes #56. Closes #55. Closes #53. Resolves outstanding issues from #32. Per all these earlier issues and PRs: - The original bin/bats symlink was causing problems on Windows. - The attempted fix from #32 created problems for install.sh. - Per #90, changing bin/bats to a one-line script in #88 broke some Bats installations that rely on symlink schemes (such as when installed via https://github.com/basherpm/basher). For an idea why I wanted to abolish using any symlinks if I could for Windows's sake, see the following results I discovered during a search for "git symlink windows": - https://github.com/git-for-windows/git/wiki/Symbolic-Links - https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ - libgit2/libgit2#4107 - https://stackoverflow.com/q/5917249 Using a method inspired by go-core.bash from https://github.com/mbland/go-script-bash, I was able to reliably compute the root of the Bats installation without using `readlink` by making use of `PWD` and `cd`. What's more, in the course of doing this, I realized libexec/bats didn't need `readlink` either, so I removed it, eliminating external dependencies and subshells. I also removed some extraneous variables and small bits of logic. On top of making install.sh, bin/bats, and libexec/bats more self-contained, resilient, and compact, the existing test suite (before the new installer and symlink tests) sped up significantly, running 0.6s-0.7s faster on my MacBook Pro (2.9 GHz Intel Core i5, 8GB RAM): Bash 3.2.57(1)-release before: 58 tests, 0 failures real 0m4.924s user 0m3.045s sys 0m1.798s Bash 3.2.57(1)-release after: 58 tests, 0 failures real 0m4.326s user 0m2.793s sys 0m1.508s Bash 4.4.23(1)-release before: 58 tests, 0 failures real 0m5.228s user 0m3.046s sys 0m1.952s Bash 4.4.23(1)-release after: 58 tests, 0 failures real 0m4.563s user 0m2.782s sys 0m1.614s

Closes #90. Closes #83. Closes #56. Closes #55. Closes #53. Resolves outstanding issues from #32. Per all these earlier issues and PRs: - The original bin/bats symlink was causing problems on Windows. - The attempted fix from #32 created problems for install.sh. - Per #90, changing bin/bats to a one-line script in #88 broke some Bats installations that rely on symlink schemes (such as when installed via https://github.com/basherpm/basher). For an idea why I wanted to abolish using any symlinks if I could for Windows's sake, see the following results I discovered during a search for "git symlink windows": - https://github.com/git-for-windows/git/wiki/Symbolic-Links - https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ - libgit2/libgit2#4107 - https://stackoverflow.com/q/5917249 Using a method inspired by go-core.bash from https://github.com/mbland/go-script-bash, I was able to reliably compute the root of the Bats installation without using `readlink` by making use of `PWD` and `cd`. What's more, in the course of doing this, I realized libexec/bats didn't need `readlink` either, so I removed it, eliminating external dependencies and subshells. I also removed some extraneous variables and small bits of logic. On top of making install.sh, bin/bats, and libexec/bats more self-contained, resilient, and compact, the existing test suite (before the new installer and symlink tests) sped up significantly, running 0.6s-0.7s faster on my MacBook Pro (2.9 GHz Intel Core i5, 8GB RAM): Bash 3.2.57(1)-release before: 58 tests, 0 failures real 0m4.924s user 0m3.045s sys 0m1.798s Bash 3.2.57(1)-release after: 58 tests, 0 failures real 0m4.326s user 0m2.793s sys 0m1.508s Bash 4.4.23(1)-release before: 58 tests, 0 failures real 0m5.228s user 0m3.046s sys 0m1.952s Bash 4.4.23(1)-release after: 58 tests, 0 failures real 0m4.563s user 0m2.782s sys 0m1.614s Also tweaks the Dockerfile to update the symlink to point to bin/bats, not libexec/bats.

Closes #90. Closes #83. Closes #56. Closes #55. Closes #53. Resolves outstanding issues from #32. Per all these earlier issues and PRs: - The original bin/bats symlink was causing problems on Windows. - The attempted fix from #32 created problems for install.sh. - Per #90, changing bin/bats to a one-line script in #88 broke some Bats installations that rely on symlink schemes (such as when installed via https://github.com/basherpm/basher). For an idea of why I wanted to keep bin/bats as a script due to how symlinks complicate things on Windows, see the following results I discovered during a search for "git symlink windows": - https://github.com/git-for-windows/git/wiki/Symbolic-Links - https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ - libgit2/libgit2#4107 - https://stackoverflow.com/q/5917249 In the course of applying these changes, I realized libexec/bats computed some extraneous variables, so I removed them, eliminating a few external processes and subshells. I also cleaned up other small bits of logic. On top of making install.sh, bin/bats, and libexec/bats more resilient and compact, the existing test suite (before adding the new test/installer.bats file) sped up significantly, running 0.6s-0.7s faster on my MacBook Pro (2.9 GHz Intel Core i5, 8GB RAM): Bash 3.2.57(1)-release before: 58 tests, 0 failures real 0m4.924s user 0m3.045s sys 0m1.798s Bash 3.2.57(1)-release after: 58 tests, 0 failures real 0m4.341s user 0m2.808s sys 0m1.540s Bash 4.4.23(1)-release before: 58 tests, 0 failures real 0m5.228s user 0m3.046s sys 0m1.952s Bash 4.4.23(1)-release after: 58 tests, 0 failures real 0m4.582s user 0m2.791s sys 0m1.643s Also tweaks the Dockerfile to update the symlink to point to bin/bats, not libexec/bats.

ethomson · 2019-02-17T23:03:49Z

Support was added in #4713

bquistorff mentioned this issue Feb 3, 2017

Devtools installation failed imbs-hl/ranger#145

Closed

mbland mentioned this issue Jun 7, 2018

bin/bats, install.sh: Fix symlink bugs bats-core/bats-core#91

Merged

2 tasks

hcs64 mentioned this issue Jun 27, 2018

Symlinks only contain path when using a git branch on Windows alexcrichton/cargo-vendor#77

Closed

KEINOS mentioned this issue Sep 9, 2018

バナー画像のファイル名にある画像サイズがおかしかったので修正しました Qithub-BOT/Qithub-ORG#129

Merged

ethomson mentioned this issue Oct 21, 2018

Support symlinks on Windows when core.symlinks=true #4713

Merged

ethomson closed this as completed Feb 17, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cloning a repo on Windows breaks symlinks #4107

Cloning a repo on Windows breaks symlinks #4107

bquistorff commented Feb 3, 2017

ethomson commented Feb 8, 2017

csware commented Mar 20, 2017 •

edited

Loading

jabbera commented Jun 14, 2017

cyberbit commented Jun 29, 2017

ethomson commented Feb 17, 2019

Cloning a repo on Windows breaks symlinks #4107

Cloning a repo on Windows breaks symlinks #4107

Comments

bquistorff commented Feb 3, 2017

Reproduction steps

Expected behavior

Actual behavior

Version of libgit2 (release number or SHA1)

Operating system(s) tested

ethomson commented Feb 8, 2017

csware commented Mar 20, 2017 • edited Loading

jabbera commented Jun 14, 2017

cyberbit commented Jun 29, 2017

ethomson commented Feb 17, 2019

csware commented Mar 20, 2017 •

edited

Loading